WGSL builtin textureSample w/derivatives test

This test is different than the pattern set by the non-derivative test. The existing test renders an array of coordinates. The coordinates might come from data passed to the shader, or they might be hard coded with multiple textureSample calls. The results are written to a storage buffer and compared to computed expected values.

This test instead renders a quad (2 triangles) to an rgba32float texture given a simple shader. It then "software renders" the expected result and compares the 2 results.

There are a large number of permutations of parameters that affect texture sampling. The sampler itself has wrapping modes and sampling modes. textureSample is influenced by texture format, coordinates, derivatives and offsets. Testing all combinations X all texture formats would make the tests too slow so, these tests focus mostly on the effect of derivatives and assume the combinations in the non-derivative case give effective coverage of the other permutations.

The tolerances for whether the actual result match the expected result are rather large. They are influenced by the OpenGL dEQP test suite which has similar tolerances. The hope is these are a good starting point to get the tests written with a structure that can be adjusted later should it be decided to make these tests more strict.

There's a chromium run here: https://dawn-review.googlesource.com/c/dawn/+/188725/2?checksPatchset=2&tab=checks

Note: another possibility is I discard this PR and try to fit derivatives into the existing (rendering a list of coords) framework. I looked into that and it's certainly possible. I can use the fragment shader's @builtin(position) as the source of the changing value for the derivative. For any call into a texture builtin I subtract the expected frag position for that call as a constant. It has to be constant otherwise the calculation would affect the derivative. But, because it would have to be a constant, that would make every call unique which makes the shader very large. If that's a better direction though I can switch.

The advantage to that direction is, testing other things that have to be constants gets more coverage. For example, if you check that test you'll see, for offset, the test parameter is true, false and if true then a bunch of pseudo random constants are used generating a shader with N calls to textureSample, one per offset. Where as in the derivatives test it just tests 2 pairs of constants and hopes that's good enough.

Requirements for PR author:

[X] All missing test coverage is tracked with "TODO" or .unimplemented().
[X] New helpers are /** documented */ and new helper files are found in helper_index.txt.
[X] Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
[X] 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.

gpuweb / cts

WGSL builtin textureSample w/derivatives test #3757