[Metal] Does not support vectorized `@dx.op.rawBufferVectorLoad` and `@dx.op.rawBufferVectorStore`

Nobody has claimed this yet.

The metal shader converter is able to convert most llvm vectorized instruction but not `dx.op.*` vectorized instructions.

Reported to apple here: https://feedbackassistant.apple.com/feedback/24705709

If I do:
```hlsl
ByteAddressBuffer In0 : register(t0);
RWByteAddressBuffer Out : register(u1);

[numthreads(1,1,1)]
void main() {
Out.Store< vector >(0, asfloat(In0.Load< vector >(0)));
}
```

I generate https://hlsl.godbolt.org/z/hz846Tb4b
```llvm
define void @main() {
%Out_UAV_rawbuf = call %dx.types.Handle @dx.op.createHandleFromBinding(i32 217, %dx.types.ResBind { i32 1, i32 1, i32 0, i8 1 }, i32 1, i1 false), !dbg !32 ; line:6 col:45 ; CreateHandleFromBinding(bind,index,nonUniformIndex)
%In0_texture_rawbuf = call %dx.types.Handle @dx.op.createHandleFromBinding(i32 217, %dx.types.ResBind zeroinitializer, i32 0, i1 false), !dbg !32 ; line:6 col:45 ; CreateHandleFromBinding(bind,index,nonUniformIndex)
%1 = call %dx.types.Handle @dx.op.annotateHandle(i32 216, %dx.types.Handle %In0_texture_rawbuf, %dx.types.ResourceProperties { i32 11, i32 0 }), !dbg !32 ; line:6 col:45 ; AnnotateHandle(res,props) resource: ByteAddressBuffer
%RawBufferVectorLoad = call %dx.types.ResRet.v16i32 @dx.op.rawBufferVectorLoad.v16i32(i32 303, %dx.types.Handle %1, i32 0, i32 undef, i32 4), !dbg !32 ; line:6 col:45 ; RawBufferVectorLoad(buf,index,elementOffset,alignment)
%2 = extractvalue %dx.types.ResRet.v16i32 %RawBufferVectorLoad, 0, !dbg !32 ; line:6 col:45
%3 = bitcast <16 x i32> %2 to <16 x float>, !dbg !33 ; line:6 col:37
%4 = call %dx.types.Handle @dx.op.annotateHandle(i32 216, %dx.types.Handle %Out_UAV_rawbuf, %dx.types.ResourceProperties { i32 4107, i32 0 }), !dbg !34 ; line:6 col:3 ; AnnotateHandle(res,props) resource: RWByteAddressBuffer
call void @dx.op.rawBufferVectorStore.v16f32(i32 304, %dx.types.Handle %4, i32 0, i32 undef, <16 x float> %3, i32 4), !dbg !34 ; line:6 col:3 ; RawBufferVectorStore(uav,index,elementOffset,value0,alignment)
ret void, !dbg !35 ; line:7 col:1
}
```
The problematic instructions being `@dx.op.rawBufferVectorLoad.v16i32` and `@dx.op.rawBufferVectorStore.v16f32`.

However if I do
```hlsl
StructuredBuffer In0 : register(t0);
RWStructuredBuffer Out : register(u1);

[numthreads(1,1,1)]
void main() {
vector Input0_16;
for (uint I = 0; I < 16; ++I)
Input0_16[I] = In0[13 + I];
vector Result16 = asfloat(Input0_16);
for (uint I = 0; I < 16; ++I)
Out[13 + I] = Result16[I];
}
```
we get a vector bitcast and a vector load store https://hlsl.godbolt.org/z/Ydonf11ra

The important part of these tests being the ` %3 = bitcast <16 x i32> %2 to <16 x float>` I wonder if it is worth reducing the hlsl code if it forces us to have to xfail Metal for DXC?

_Originally posted by @farzonl in https://github.com/llvm/offload-test-suite/pull/1463#discussion_r3929452613_

Start by reproducing the two HLSL cases and comparing their generated LLVM IR using the linked Godbolt examples. Focus on the vectorized dx.op.rawBufferVectorLoad and dx.op.rawBufferVectorStore instructions and the linked Metal converter behavior; the issue does not identify a file, test, or definitive completion criterion.

Written by the indexing model from the issue text.