Add WaveReadLaneAt tests

[bob80905]

This PR implements testing for the WaveReadLaneAt intrinsic. It's an improved copy of @inbelic's work here: #295

• WaveReadLaneAt.[16|32|64].test adds testing of the basic types (and vectors)
• WaveReadLaneAt.udt.test adds testing for a matrix, user defined struct and for floating point edge-case values
• WaveReadLaneAt.index.test adds testing of various use-cases with different indices

Resolves: #144

[llvm-beanz]

@bogner, I know we were talking about needing to double up testing, but I'm curious for your thoughts on this one.

Combining double and int64 in the same test means we don't run this on devices that only support one or the other. While I think int64 is fairly universal at this point because 64-bit pointer math kinda requires it, there are a number of mobile architectures that don't support double (including Apple GPUs).

Does it make sense to combine 64-bit types or should we split them?

[bogner]

Yeah, splitting these makes sense. I suspect as a rule of thumb any time we're REQUIREing two different features in these tests we should probably split them up for maximum test coverage.

[spall]

Should we also have a test where WaveReadLaneAt is called in one or more switch statement cases?

[llvm-beanz]

We should be careful using switch statements in tests. They should be fine as long as no case labels have fall through. Even trivial fall through is UB in SPIRV.

[inbelic]

LGTM, just if we should split up the testcase as mentioned

[kmpeng]

Should there be bool tests for WaveReadLaneAt? I see that it supports bool in the HLSL headers