Provide a way for applications to use a single adapter

The current UR loader, to support multiple adapters, has an indirection layer that creates and maintains wrappers around UR entities (or function class types, i.e., platform, device and so on) that store a pointer to adapter functions. If there's only one adapter, this layer is unused, and the loader calls the adapter functions directly.

This indirection adds an extraneous overhead for applications that use only one adapter but have more available in the system. This issue is to devise a way to allow applications to load and use only the desired adapter implementation, thus avoiding the overhead.

Possible solutions:

• The UR_ADAPTERS_FORCE_LOAD environmental variable can be set with a desired adapter, forcing the loader to use it. This is already possible.
• Reintroduce platform_flags to urInit, with a way of selecting a single adapter.
  • Something like UR_PLATFORM_USE_FIRST. But this might be hard to use since the order of adapters is unspecified.
  • Alternatively, we could create a flag per known platform, something like: UR_PLATFORM_L0, UR_PLATFORM_CUDA, UR_PLATFORM_HIP, and then this could be used like this: urInit(0, UR_PLATFORM_L0 | UR_PLATFORM_CUDA);. This would only work with predefined platforms.
• Add a way to programmatically filter platforms at urInit, for example: urInit(0, [](struct platform_descriptor *d) -> bool { return strcmp(d->name, "ur_adapter_level_zero") == 0; }). This might be clunky to use from C, but I think is the most universal.
• Add a way of unloading platforms post-initialization. Software would iterate over available platforms and would either call urPlatformUnload on the ones it doesn't intend to use or urPlatformUseOnlyThis (can't think of a name right now :-)) on the one it does. This fits into the existing API, but might be error-prone and tricky to implement safely.

Start with source/loader/ur_ldrddi.cpp to understand the current indirection and direct-call paths, then inspect urInit and the UR_ADAPTERS_FORCE_LOAD behavior. Compare the proposed selection and unloading approaches against the existing loader API. Done means an agreed, safe way for applications to select one adapter and avoid the unnecessary wrapper overhead.