Add support for resource arrays to the offload test suite

[hekota]

Introduces support for resource arrays across the offload test suite, including:

• Data input and output handling
• Comparison of expected results
• Integration with both DirectX and Vulkan runtimes (Metal is not supported yet)

A new property ArraySize has been added to the Buffer definition. If ArraySize is 1 (the default), the Data field of the Buffer remains unchanged:

Data: [0, 1, 2, 3]

If ArraySize is greater than 1, the Data field must be specified as a list of arrays:

Data:
  - [0, 1, 2, 3]
  - [4, 5, 6, 7]
  - [8, 9, 10, 11]

If the resource array includes resources with counters, their values will be output using the Counters field:

Counters: [1, 2, 3]

Closes llvm/wg-hlsl#291

[llvm-beanz]

One question I have from a design perspective is should the array-ness be part of the buffer, or part of the resource.

This PR makes them part of the buffer, my inclination had been to make it part of the resource. The reason I had thought to attach it to the resource is to allow an array to be comprised of buffers of different sizes or underlying data types. Curious for thoughts on whether or not that is important to support.

[hekota]

One question I have from a design perspective is should the array-ness be part of the buffer, or part of the resource.

This PR makes them part of the buffer, my inclination had been to make it part of the resource. The reason I had thought to attach it to the resource is to allow an array to be comprised of buffers of different sizes or underlying data types. Curious for thoughts on whether or not that is important to support.

I considered making the array-nest part of the Resource, but since all elements in a resource array must share the same type, stride, and other characteristics, it seemed more appropriate to place the array-nesting on the Buffer. Moving it to the resource level would make the buffer definitions repetitive and require additional validation to ensure consistency across elements.
That said, I acknowledge it’s a bit odd to have a Buffer definition that effectively encapsulates multiple buffers.

Currently, we don’t support varying sizes for individual resources in an array, but that could be added if needed.

[llvm-beanz]

I considered making the array-nest part of the Resource, but since all elements in a resource array must share the same type, stride, and other characteristics, it seemed more appropriate to place the array-nesting on the Buffer. Moving it to the resource level would make the buffer definitions repetitive and require additional validation to ensure consistency across elements.

This makes sense to me. I'm glad I wasn't alone in thinking the other way around.

[llvm-beanz]

A few comments, but this mostly looks good to me.

[llvm-beanz]

@spall Did we decide on using XFAIL for things that aren't yet supported but are planned?

[hekota]

I think we were talking about introducing UNIMPLEMENTED: but it had not been done yet. I'll at least change the UNSUPPORTEDs in this change to XFAILs.