Add more cases to canvas reftest with device loss

[kainino0x]

Test for gpuweb/gpuweb#4606
Expected results need careful review.
See discussion here about what the spec says: #3669 (review)

Issue: #3251

---

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]

cc @perryuwang

[perryuwang]

So my understanding is as follows, is it accurate?
When canvas is configured but getCurrentTexture is not called:

• Display a transparent image if configure()d as transparent.
• Display a black image if configure()d as opaque.

[kainino0x]

I think so. It should be the same regardless of whether getCurrentTexture is called: both configure() and getCurrentTexture() wipe the canvas to blank (transparent or opaque depending on the configuration).

[kainino0x]

gpuweb/gpuweb#4606 was resolved, and this test should still be correct.

[toji]

A couple of nits but LGTM.

[toji]

Why not initialize threw to false instead of setting it here?

[toji]

µNit: It's a little strange to have some of these colors be 6 hex digits and others be 8? I feel like the intent might be a bit clearer if we explicitly put the last FF/00 on them to indicate the expected alpha state?

[kainino0x]

This is no longer valid because the spec allows multiple behaviors. The existing test also isn't valid anymore (not sure if it was removed already or not).

It is possible to test multiple behaviors:
https://web-platform-tests.org/writing-tests/reftests.html#multiple-references
So this test should be fixed to do that. But we might not be able to test so many cases in a single reftest anymore, since behavior can vary between setups.