Drop llvm.compiler.used GV?

Before https://github.com/llvm/llvm-project/commit/1120d8e6f799 compiler FE would place `llvm.compiler.used` GV in private address space and translator would error out facing it due to recently added diagnostics. Before this diagnostic we were translating it to SPIR-V module to `OpVariable` with `llvm.compiler.used` name and function storage class and in SPIRVReader we would drop this GV completely, see https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/main/lib/SPIRV/SPIRVReader.cpp#L3442 .

Right now with the mentioned community patch translator no longer drop the GV and it survives the translation. But reverse translation would not be 100% correct, we also need to change section of this GV to `llvm.metadata`. We could add the section, but considering [definition from the LangRef](https://llvm.org/docs/LangRef.html#the-llvm-compiler-used-global-variable):

> On targets that support it, this allows an intelligent linker to optimize references to the symbol without being impeded as it would be by @llvm.used.

so strictly speaking, our target here is SPIR-V and SPIR-V doesn't have support for such magic GV, so going to non-necessarily-LLVM-based backend such GV might remain to be unresolved (an we don't have appending linkage type in SPIR-V to help with properly resolving the GV). And IMHO it's better to not generate `OpVariable` when facing `llvm.compiler.used` at all also considering that relying on its information passed for optimized from FE to device's compiler is a bad idea. WDYT?

Read lib/SPIRV/SPIRVReader.cpp around line 3442 and the linked LLVM LangRef definition for llvm.compiler.used. First resolve whether SPIR-V should drop this global variable or preserve it with metadata, then trace the forward and reverse translation paths; done means the agreed behavior is implemented without an incorrect surviving representation.

Written by the indexing model from the issue text.