[SYCL][UR] Use Windows proxy loader for UR

[callumfare]

The issues with DLLs and teardown of global objects on Windows is well documented, and was the reason for the use of the pi_win_proxy_loader library in SYCL-RT. When we ported from PI to UR, we ported this library (it's now called ur_win_proxy_loader), but it was not actually fully utilized. SYCL-RT still linked with ur_loader.dll and still experienced issues with race conditions in the teardown of SYCL-RT and Unified Runtime. See #14768.

This PR reintroduces the proxy loader as it was previously used with PI. The UR loader (ur_loader.dll) is loaded via LoadLibraryEx at initialization, and is therefore not cleaned up too early for normal teardown to occur.

This necessitates changing the signature of Plugin->call to look like it did with PI, taking an enum template argument to specify which UR entry point to call.

On Windows, when each plugin (which is a wrapper over a UR adapter) is loaded, it populates a table of function pointers to each API entry point in the UR loader. When UR entry points are called, the function pointer is retrieved from the table. This is more or less equivalent to the previous PI implementation.

On Linux, the UR loader is dynamically linked as before. The Plugin->call methods just use the regular UR functions rather than programmatically looking up the symbols.

For the unittest executables, the UR loader is still dynamically linked as before to avoid having to introduce noisy changes to the tests, and since we aren't concerned about teardown issues there.

The implementation of these changes in the runtime should avoid as much overhead as possible (and be no worse than PI), but suggestions on how to improve and tidy things are more than welcome.

Associated UR change: oneapi-src/unified-runtime#2045

[cppchedy]

LGTM - detail/bindless_images.cpp

[callumfare]

The E2E failure was just in the cleanup, the tests actually passed. However, the Windows E2E run took over an hour which is a lot slower than normal. This PR is expected to introduce a very small overhead but nothing like a 50% slowdown. I'll investigate, but this shouldn't be merged in the meantime.

On further investigation it seems like this was a change we made to shutdown_win causing hangs. I've reverted that part of the PR, and also not re-enabled any new E2E tests to be conservative. Assuming CI is ok I think this is ok to merge.

[pbalcer]

lgtm, just one nit.

[callumfare]

@intel/llvm-gatekeepers Please merge when possible

[sarnex]

@callumfare I think this PR also caused this error too:

 In file included from /__w/llvm/llvm/build/_deps/unified-runtime-src/source/adapters/opencl/adapter.cpp:11:
/__w/llvm/llvm/build/_deps/unified-runtime-src/source/adapters/opencl/common.hpp:317:29: error: 'cl_mutable_base_config_khr' does not name a type; did you mean 'cl_mutable_dispatch_config_khr'?
  317 |                       const cl_mutable_base_config_khr *mutable_config);

That's from my PR here and we also see it in Mac postcommit here.

Any ideas? Should we revert this? Build is broken for everyone using HEAD.

[callumfare]

@sarnex That's unrelated to this change. It appears to be caused by this change to OpenCL-Headers - KhronosGroup/OpenCL-Headers@7258b9e - which just merged. We must be pulling the tip of the repo rather than a specific commit

[sarnex]

@callumfare Nice find, I didn't understand how this PR could cause the problem either. I'll try to fix it.

FYI @EwanC

[sarnex]

This PR should fix it but then I have to bump the version here.

oneapi-src/unified-runtime#2067