Resolve libdxcompiler.so memory leak

After the changes introduced in https://github.com/microsoft/DirectXShaderCompiler/pull/7451, it was discovered that a memory leak had been either produced, or revealed in the linux environment.

With this cmake configuration:

# cmake in linux env from cwd right above ./DXC repo:
cmake ./DXC -B ./hlsl.bin -C ./DXC/cmake/caches/PredefinedParams.cmake -DCMAKE_BUILD_TYPE=Debug -G Ninja -DSPIRV_BUILD_TESTS=ON -DCMAKE_C_COMPILER=clang-18 -DCMAKE_CXX_COMPILER=clang++-18 -DLLVM_ENABLE_WERROR=On -DLLVM_USE_SANITIZER='Address;Undefined' -DLLVM_ENABLE_LIBCXX=On -DLLVM_USE_LINKER=lld

when running ./hlsl.bin/bin/dxc --version, the Leak Sanitizer detects this leak

=================================================================
==32533==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x5614aa77d6bd in operator new(unsigned long) (/home/jbatista/repos/hlsl.bin/bin/dxc-3.7+0x4fe6bd) (BuildId: fd646a5ae4e18783)
    #1 0x7f744fbaad12  (<unknown module>)
    #2 0x7f744fbaa465  (<unknown module>)
    #3 0x7f744fba8a7b  (<unknown module>)
    #4 0x7f745a2b147d in call_init elf/dl-init.c:70:3

SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).

Separately, one can use valgrind to detect this leak, by configuring cmake without the DLLVM_USE_SANITIZER argument above, and when building DXC, instead of ninja, using CCC_OVERRIDE_OPTIONS=s/-g/-gdwarf-4/ ninja so that valgrind can correctly interpret the debug symbols.

It is known that in a clean environment, using lldb with lldb -- ./hlsl.bin/bin/dxc --version, then immediately running image list from within lldb, no libraries are loaded, the only associated image is dxc. But after running dxc --version with r, and rerunning image list, libdxcompiler.so appears to still be loaded:

Separately, if one changes \tools\clang\tools\dxc\CMakeLists.txt:27 to simply target_link_libraries(dxc dxclib), then the leak increases to 32 bytes.

This issue will be resolved when there is confidence that there is no memory leak, and an appropriate design for loading and unloading dynamic libraries is implemented. The proper solution to the leak may be to make some edits to the CMakeLists.txt file mentioned above.

Start with tools/clang/tools/dxc/CMakeLists.txt:27 and reproduce the leak using the issue's CMake configuration and dxc --version under LeakSanitizer. Compare the result with Valgrind and inspect library loading in lldb using image list. Done means the loading and unloading design is appropriate and dxc --version reports no leak.