This was a known issue in our IR representation, which was now biting a user. The basic problem is that in code like the following:

```hlsl
RWStructureBuffer<float4> buffer;
...
buffer[index].xz = value;
```

we ideally want to be able to reproduce the original HLSL code exactly, but that requires directly encoding the way that this code writes to two elements of a vector, but not the others.

The currently lowering strategy we had produced IR something like:

```hlsl
float4 tmp = buffer[index];
tmp.xz = value;
buffer[index] = tmp;
```

That transformation might seem valid, but it has some big problems:

* It generates UAV reads that are not needed, which could impact performance
* It performs read-modify-write operations on memory that the programmer didn't explicitly write, which could create data races

The fix here is somewhat obvious: if the "base" of a swizzle operation on a left-hand side resolves to a pointer in our IR, then we can output a "swizzled store" instead of the read-modify-write dance. We currently keep the read-modify-write around since it is potentially needed as a fallback in the general case.

Along the way I also tried to make sure that we handle the case where we have a swizzle of a swizzle on the left-hand side:

```hlsl
buffer[index].xz.y = value;
```

That code should behave the same as `buffer[index].z = value`. I am currently detecting and cleaning up this logic in the lowering path for `SwizzleExpr`, because that is the only place in the lowering logic that "swizzled l-values" currently get created.