"platform" CTS tests cause bizzare linker behaviour with `libze_loader.so` when linked with `-flto`

Reproduction:
Add the following to /build/_deps/level-zero-loader-src/source/lib/ze_lib.cpp:

__attribute__((destructor)) void print_dtored() {
    std::cout << "ze_lib has been dtored.\n";
};
__attribute__((constructor)) void print_ctored() {
    std::cout << "ze_lib has been ctored.\n";
};

This will print when libze_loader has been opened and closed.

Build, and run bin/test-platform. Note that print_ctored is printed once at the start of testing, and print_dtored is printed once at the end of testing.

If you set -flto on the ze_loader target (for example, via target_compile_options(ze_loader PRIVATE -flto) just after add_ur_adapter(ur_adapter_level_zero ...)), and rerun the tests, you will note that print_dtored at the end of the first test.

What happens next depends on a number of factors:

• If LD_LIBRARY_PATH is not set, then the program will search for a libze_loader.so in the system path, possibly ending up with /lib/x86_64-linux-gnu/libze_loader.so.1. Since this is different to build/lib/libze_loader.so, they don't have access to the same global state, and problems happen.
• If LD_LIBRARY_PATH is set to build/lib and the printing code is present, it segfaults trying to write to stdout.
• If LD_LIBRARY_PATH is set to build/lib and the printing code is removed, the test passes. GDB indicates that print_ctored is still being called once per test, even if it doesn't print anything.

Reproduce the behavior by adding the constructor and destructor probes to /build/_deps/level-zero-loader-src/source/lib/ze_lib.cpp, enabling -flto on the ze_loader target, and running bin/test-platform. Compare runs with and without LD_LIBRARY_PATH=build/lib; done should avoid premature library destruction, repeated constructor behavior, and the reported stdout segfault.