Add a test for many timestamp query sets

[greggman]

This test is because Metal has a limit of 32 timestamp query sets. Implementations are supposed to workaround this limit by allocating larger metal sets and having WebGPU set be subsets in those larger sets.

This is especially important as the limit is 32 per process so a few pages making a few queries would easily hit the limit and prevent pages from running.

In issue 5261 65k queries was mentioned so this test creates 65536 (not sure if that's the same 65k Kai was referring to)

I think that maybe the issue should be reopened and the spec should state the minimum or it should defer it to the CTS. Except for a few explicit OOM tests, we don't allow implementations to return out-of-memory for all buffers and textures and claim to pass the CTS and I think we should do the same here and require implementations to pass this test too. Is 65536 good for this?

---

Requirements for PR author:

• All missing test coverage is tracked with "TODO" or .unimplemented().
• New helpers are /** documented */ and new helper files are found in helper_index.txt.
• Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
• Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

• Tests are properly located in the test tree.
• Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[kainino0x]

In issue 5261 65k queries was mentioned so this test creates 65536 (not sure if that's the same 65k Kai was referring to)

That was based on Mike's comment:

With a global limit of 32 sample buffers, 65,536 timestamp queries should be able to be in flight before we run into this limitation.

It may be good to (also) test more, but knowing that some implementations may choose not to deal with that because it's probably vanishingly unlikely to happen in practice.

[kainino0x]

It may be good to (also) test more, but knowing that some implementations may choose not to deal with that because it's probably vanishingly unlikely to happen in practice.

I'm unsure whether it's possible to deal with that in a single command buffer (like this test). Maybe the implementation could split the command buffer.

If across multiple command buffers it would be a test of the implementation's ability to clean up and reuse past slots, I think.