*.worker.js files are not supported, but generated by CTS upstream

[ErichDonGubler]

Upstream WebGPU CTS currently generates variants of WPT test manifests that run in dedicated worker contexts in a webworker top-level directory (i.e., tests/webworker/api/operation/…/requestAdapter.worker.js. These files are "converted" to HTML test by wptrunner and reported as *.worker.html entries in WPT execution reports.

When moz-webgpu-cts encounters these reports, it assumes that the corresponding metadata path should simply add an ini file extension to the reported HTML URL path, viz., meta/webworkers/api/operation/…/requestAdapter.worker.html.ini, rather than …/requestAdapter.worker.js.ini. These incorrectly placed metadata files are subsequently (rightfully) ignored by wptrunner, because they're not in the right place.

[ErichDonGubler]

Solution space I see:

1. By checking for a .worker suffix in the reported test's basename, we could "just" assume that anything ending in *.worker.html actually corresponds to a *.worker.js manifest. Support *.worker.js metadata and reports #119 does this, and it seems like a relatively easy change to make (though it will make the TestPath model significantly more complicated).
2. We could build a registry of all test manifest files (i.e., tests/**), and then refer to it when we check where a reported test entry could have been specified. This creates more data dependency in moz-webgpu-cts, which I'm wary of. It also seems a lot more I/O and data than I think are necessary.

[ErichDonGubler]

Resolved by gpuweb/cts#3835; it turns out, WebGPU CTS was unintentionally overlapping its naming convention of files with WPT's. 😅

I'm migrating the scope of "once we have worker.js tests, we'll need support" over to #122. Otherwise, this is done!