HLSL uses CreateRuntimeFunction for three intrinsics. This is pretty
unusual thing to do, and doesn't match what the rest of the file does.

I suspect this might be because these are convergent calls, but the
intrinsics themselves are already marked convergent, so it's not
necessary for clang to manually add the attribute.

This does lose the spir_func CC on the intrinsic declaration, but again,
CC should not be relevant to intrinsics at all.

- **Reapply "[HLSL][SPIRV] Add vk::constant_id attribute." (#144812)**
- **Fix memory leak.**

Reverts llvm/llvm-project#143544

The vk::constant_id attribute is used to indicate that a global const
variable
represents a specialization constant in SPIR-V. This PR adds this
attribute to clang.

The documentation for the attribute is
[here](https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/SPIR-V.rst#specialization-constants).

The strategy is to to modify the initializer to get the value of a
specialize constant for a builtin defined in the SPIR-V backend.

Implements https://github.com/llvm/wg-hlsl/pull/287

Fixes https://github.com/llvm/llvm-project/issues/142448

---------

Co-authored-by: Nathan Gauër <github@keenuts.net>

The SPIR-V backend does not have access to the original name of a
resource in the source, so it tries to create a name. This leads to some
problems with reflection.
    
That is why start to pass the name of the resource from Clang to the
SPIR-V backend.
    
Fixes #138533

This commit adds code to lower WaveGetLaneCount() into the SPV or DXIL
intrinsic. The backends will then need to lower the intrinsic into
proper SPIR-V/DXIL.

Related to #99159

Adds resource name argument to `llvm.dx.handlefrombinding` and `llvm.dx.handlefromimplicitbinding` intrinsics.
SPIR-V currently does not seem to need the resource names so this change only affects DirectX binding intrinsics.

Part 2/4 of https://github.com/llvm/llvm-project/issues/105059

Update how Sema Checking is done for HLSL builtins to allow for better
error messages, mainly using 'err_builtin_invalid_arg_type'.
Try to follow the formula outlined in issue #134721 
Closes #134721

There were some issues with these ops:
- The overload wasn't being specified (`dx.op.dot4AddPacked` vs
`dx.op.dot4AddPacked.i32`)
- The versioning wasn't correct (These ops were added in SM 6.4)
- The argument order was off - while the HLSL function has the
accumulator as the last argument, the DXIL op lists it first.

This fixes the DXIL.td definition and adjusts the LLVM DX and SPIRV
intrinsics to match the argument order in DXIL rather than the argument
order in HLSL.

Fixes #139018

Adds constructor for resources with implicit binding and applies it to
all resources without binding at the global scope.
Adds Clang builtin function
`__builtin_hlsl_resource_handlefromimplicitbinding` that gets translated
to `llvm.dx|spv.resource.handlefromimplicitbinding` intrinsic calls.
Specific bindings are assigned in DXILResourceImplicitBinding pass.

Design proposals:

https://github.com/llvm/wg-hlsl/blob/main/proposals/0024-implicit-resource-binding.md

https://github.com/llvm/wg-hlsl/blob/main/proposals/0025-resource-constructors.md

One change from the proposals is that the `orderId` parameter is added
onto the constructor. Originally it was supposed to be generated in
codegen when the `llvm.dx|spv.resource.handlefromimplicitbinding` call
is emitted, but that is not possible because the call is inside a
constructor, and the constructor body is generated once per resource
type and not resource instance. So the only way to inject instance-based
data like `orderId` into the
`llvm.dx|spv.resource.handlefromimplicitbinding` call is that it must
come in via the constructor argument.

Closes #136784