[SPIRV] llvm.used and related variables not properly handled

Previously, there was no special handling for variables like llvm.used in the SPIR-V backend, so the backend would just try to emit them as normal variables.

This caused many problems, one common example is the constant initializer for the variables would contain IR that illegal and cannot be legalized (ex. addrspacecast from UniformConstant to Generic), so the backend would blow up saying these instructions are illegal.

So, changes were made to skip emission of these variables and any types defined by them, see the PRs at the bottom of this bug report.

However, if we take a step back, it's not totally clear what these variables should do in SPIR-V.

For example, the llvm.used definition is If a symbol appears in the @llvm.used list, then the compiler, assembler, and linker are required to treat the symbol as if there is a reference to the symbol that it cannot see (which is why they have to be named)., but it's unclear what compiler, assembler and linker mean in this context (reference)

In addition, out-of-tree tools are required to use SPIR-V with Clang, such as spirv-as and spirv-link, and these tools seem to optimize out unreferenced variables today.

We need to:

1. Define what llvm.used and related variables should do in SPIR-V
2. Determine what impact the results of 1) have on the SPIR-V backend as well as out-of-tree tools such as those in SPIRV-Tools
3. Possibly define a new SPIR-V extension
4. Implement any changes to the relevant software projects

See the below PRs for context:

https://github.com/llvm/llvm-project/pull/162678
https://github.com/llvm/llvm-project/pull/179498

Start by reading the linked LLVM pull requests and the definitions of llvm.used and related variables in the issue. Then determine the intended SPIR-V behavior and its impact on the SPIR-V backend, spirv-as, and spirv-link; done requires agreed semantics and any resulting implementation changes.