[NFI]: XPUBackend refactoring to facilitate arch-specific implementations

[AndreyPavlenko]

The purpose of this refactoring is to simplify development for new architectures by subclassing the base class instead of adding conditional code blocks.

The main changes:

• Allow metaclasses injection: use XPUBackendMeta from the .meta submodule as the metaclass, if it exists.
• Try to find an arch-specific implementation in the .arch.<name> submodule.

[etiotto]

Wondering whether we should use easier to understand alternative. Have you considered:

1. Inheritance: create a base class that can be derived (my preference)
2. class Decorators to modify the behavior of the BE after creation

[AndreyPavlenko]

1. Inheritance: create a base class that can be derived (my preference)

XPUBackend is the base class. Arch-specific implementations derive from it and override the required methods. For example, they could override get_llir_passes() and add/remove passes.

2. class Decorators to modify the behavior of the BE after creation

It could be done, by defining a metaclass, but the inheritance should be used in most use-cases.

[whitneywhtsang]

@AndreyPavlenko please resolve the merge conflicts, and merge it tomorrow as there are no more review comments.

[AndreyPavlenko]

Seems there is some issue with CI. I see the same errors on the main branch:
RuntimeError: 0 active drivers ([]). There should only be one.

[whitneywhtsang]

Seems there is some issue with CI. I see the same errors on the main branch: RuntimeError: 0 active drivers ([]). There should only be one.

Should be fixed now.

[AndreyPavlenko]

The SPIRVRunner test is also failing.

[kwasd]

Should be fixed after either merging #5459 or fixing #5458

[kwasd]

As #5459 is approved, you could now git cherry-pick 95dcbd5f567be0f1f7d502dc75007ccea1d8b406 to save time before #5459's checks are completed