test: refactor WPTRunner and enable parallel WPT execution

[panva]

This PR reintroduces #47283 but with more refactoring done to the runner to get around the issue that caused it to get reverted in #47627.

The issue at hand was that upon test completion the worker gets intentionally terminated, the worker got terminated based on a Map<string, Worker> where the key is the filename. That was not a problem until concurrency got introduced which meant that the same file but with different query string variants which didn't affect the key were added to the Map. This has lead to some multi variant test workers to get terminated. I've fixed this issue with the refactors explained below and confirmed that it's fixed by comparing the number of individual executed tests to be the same as on main (and in record time).

Screenshot

I've refactored the runner as follows:

• variants are no longer a second iteration within WPTRunner.prototype.runJsTests()
  • variants are instead detected during StatusLoader.prototype.load() and each variant gets it's own WPTTestSpec instance.
• methods where filename was used as an argument get a WPTTestSpec instance instead
• referencing WPTTestSpec instances in maps is no longer done with their filename but instead a unique Symbol Sets are used instead.
  • this means when a spec completes the worker that gets terminated is always the correct one
• more type annotations were added

With this in place then

• When it comes to worker management a unique Symbol per WPTTestSpec is now used the WPTTestSpec is now used instead of string/symbol references.
• (no change) When it comes to expectation files WPTTestSpec's filename continues to be used
• (no change) When it comes to the WPT Report WPTTestSpec's filename + variant continues to be used

Additionally:

• it is now possible to run a single test with a variant like so

./node ./test/wpt/test-webcrypto.js 'generateKey/successes_RSA-PSS.https.any.js?11-20'

• failed test commands get printed using the above syntax when the failure is within a variant test
• the logs got cleaned up a bit
• ResourceLoader.prototype.read got split into read and readAsFetch, the former is used within the WPTRunner, the latter only from the spawned workers

I will apply dont-land-* labels to observe the behaviour for a while before eventually landing this on Current by removing dont-land-on-v20.x PRs that should not land on the v20.x-staging branch and should not be released in v20.x.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/51380/

note to look into https://ci.nodejs.org/job/node-test-commit-osx/51831/nodes=osx11-x64/

edit: I've stress tested wpt/test-timers in CI as well as locally and couldn't get a new hit on this failure. I'm not going to mark it as flaky now but if it resurfaces, since it's timers related marking it flaky in WPT would be the right course of action.

edit2: Having had a look at the reliability reports, i'm going to open a separate PR to skip the flaky test (#47646)

edit3: I'll move these the few WPTs from wpt/test-timers to test/sequential in a separate PR. #47657

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/51461/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/51462/

[nodejs-github-bot]

Landed in a5ce18f

[aduh95]

@panva would you be able to backport this to v18.x-staging?

[panva]

@aduh95 I think it's best to leave these changes out of v18.x and believe we can backport #47821 more easily instead.