wgsl: Add validation test for min/max builtin functions

[toji]

Add validation test for min/max builtin functions

Starting off with a simple set of test to make sure I'm doing it right. :) Biggest question for me is for the bad args tests, should we be testing things like "both args are the same type and both are bad?"

Also, these two files differ by 2 chars. Feels like that should be combined, but I'm not sure what sort of patterns we have in place for doing so, or if it's actually desirable.

---

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.

[dneto0]

If this were 3 days I ago I would have said "perfect!".

But @ben-clayton had feedback for me for how to improve this kind of test.
See updated #3496 for his feedback and how I adapted.

1. combine kBadArgs and kGoodArgs into one dictionary kArgCases, where there is one good case named 'good'
2. the 'bad_args' test becomes 'args'
3. I also modified the must_use case to have both good and bad cases, parameterizing it on 'use' over false and true.

[dneto0]

Add validation test for min/max builtin functions

Starting off with a simple set of test to make sure I'm doing it right. :) Biggest question for me is for the bad args tests, should we be testing things like "both args are the same type and both are bad?"

I don't think that's needed. As long as there's at least one bad case for each argument position, that's ok. No way we want to do the entire power set.

Also, these two files differ by 2 chars. Feels like that should be combined, but I'm not sure what sort of patterns we have in place for doing so, or if it's actually desirable.

I like keeping the two separate. Makes it really easy to spot all (actually most) of the functionality for a given builtin.

E.g. just today @jrprice told me there was already centralized must-use testing for a bunch of builtins. But when I added the dp4a validation I didn't know about it. We decided to move all must-use testing for builtins into per-builtin tests, like we have here. #3502

[toji]

Thanks for the feedback! Updated both tests to match the newer patterns you pointed out.

[dneto0]

Thanks!