[Metal] Bindings for Metal seem to be broken when cbuffers are present

Nobody has claimed this yet.

When trying to write tests for cbuffers, I'm seeing a lot of strange and broken behaviours under Metal.

Consider the following test:

```
#--- source.hlsl

#if defined(__spirv__) || defined(__SPIRV__)
#define REGISTER(Idx)
#else
#define REGISTER(Idx) : register(Idx, space0)
#endif

RWBuffer In REGISTER(u0);
RWBuffer Out REGISTER(u1);

cbuffer CB0 REGISTER(b0) {
int Constant;
}

[numthreads(8,1,1)]
void main(uint3 TID : SV_GroupThreadID) {
Out[TID.x] = Constant;
}

//--- pipeline.yaml

---
Shaders:
- Stage: Compute
Entry: main
DispatchSize: [1, 1, 1]
Buffers:
- Name: In
Format: Int32
Data: [ 1, 2, 3, 4, 5, 6, 7, 8]
- Name: Out
Format: Int32
Data: [ 9, 10, 11, 12, 13, 14, 15, 16]
- Name: cbuffer
Format: Int32
Data: [ 4, 0, 0, 0]
DescriptorSets:
- Resources:
- Name: In
Kind: RWBuffer
DirectXBinding:
Register: 0
Space: 0
- Name: Out
Kind: RWBuffer
DirectXBinding:
Register: 1
Space: 0
- Name: cbuffer
Kind: ConstantBuffer
DirectXBinding:
Register: 0
Space: 0
...
#--- end

# UNSUPPORTED: Clang
# RUN: split-file %s %t
# RUN: %dxc_target -T cs_6_0 -Fo %t.o %t/source.hlsl
# RUN: %offloader %t/pipeline.yaml %t.o | FileCheck %s

# CHECK: Name: In
# CHECK: Format: Int32
# CHECK: Data: [ 1, 2, 3, 4, 5, 6, 7, 8 ]
# CHECK: Name: Out
# CHECK: Format: Int32
# CHECK: Data: [ 4, 4, 4, 4, 4, 4, 4, 4 ]
```

This simply assigns the constant value to every value of the output. The input is untouched.

However, the results under Metal are very strange:
```
Buffers:
- Name: In
Format: Int32
Data: [ 0, 0, 0, 0, 0, 0, 0, 0 ]
OutputProps:
Height: 0
Width: 0
Depth: 0
- Name: Out
Format: Int32
Data: [ 9, 10, 11, 12, 13, 14, 15, 16 ]
OutputProps:
Height: 0
Width: 0
Depth: 0
- Name: cbuffer
Format: Int32
Data: [ 4, 0, 0, 0 ]
OutputProps:
Height: 0
Width: 0
Depth: 0
```

Here, we see that the "In" buffer has been zero'd out, even though we didn't attempt to modify it at all, and the "Out" buffer hasn't been modified at all. We would expect that the "Out" buffer was filled with "4"s and the "In" buffer was untouched.

Start with the inline split-file reproducer and run the shown dxc_target, offloader, and FileCheck commands on Metal. Compare the reported buffer contents with the CHECK expectations, then trace the Metal handling of the In, Out, and cbuffer bindings. Done means the input remains unchanged and Out contains eight 4s.

Written by the indexing model from the issue text.