[DirectX] RawBuffer Stores of double vectors indices are incorrect

We found an issue when switching the FMA long vector tests to using ByteAddressBuffer that the rawBufferStore indicies were off. We need a proper investigation into what is going on.

Looks like a bug in clang: https://hlsl.godbolt.org/z/sP6qboW1j

The indices we store to look suspect:
```llvm
call void @dx.op.rawBufferStore.i32(i32 140, %dx.types.Handle %4, i32 0, i32 undef, i32 %101, i32 %105, i32 %102, i32 %106, i8 15, i32 4), !dbg !250
call void @dx.op.rawBufferStore.i32(i32 140, %dx.types.Handle %4, i32 0, i32 undef, i32 %103, i32 %107, i32 %104, i32 %108, i8 15, i32 4), !dbg !250
...
call void @dx.op.rawBufferStore.i32(i32 140, %dx.types.Handle %4, i32 32, i32 undef, i32 %113, i32 %117, i32 %114, i32 %118, i8 15, i32 4), !dbg !250
call void @dx.op.rawBufferStore.i32(i32 140, %dx.types.Handle %4, i32 32, i32 undef, i32 %115, i32 %119, i32 %116, i32 %120, i8 15, i32 4), !dbg !250
```

We're storing two sets of two doubles at offset 0, clobbering each other, and then two sets at offset 32, clobbering each other again. These offsets should be 0, 16, 32, and 48.

_Originally posted by @bogner in https://github.com/llvm/offload-test-suite/pull/1516#discussion_r4009703662_

Start with the linked HLSL Compiler Explorer reproduction and the FMA long vector tests that switched to ByteAddressBuffer. Inspect the generated rawBufferStore calls and trace why double-vector stores use offsets 0, 0, 32, and 32 instead of 0, 16, 32, and 48. Done means the cause in clang is identified and the incorrect indices are corrected or covered by a regression test.

Written by the indexing model from the issue text.