WIP: use Node built-in test runner with concurrency

[domenic]

This seems to mostly work. At least, it works for to-upstream web platform tests, going from 18.7 seconds (Node.js built-in runner, no concurrency) to 9.7 seconds (Node.js built-in runner, concurrency) on my system.

For normal web platform tests, I tried { concurrency: true } (equivalent to { concurrency: 31 } on my system) and it hung for a long time, before outputting a ton of failures, but also a good amount of successes. Most of the failures were ECONNREFUSED against the web platform tests server, i.e., I was probably DOSing myself. I'm trying { concurrency: 4 } now and results are streaming in, in a way that suggests they're being chunked and done concurrently. Maybe I can even bump it up? { concurrency: 8 } seemed to blow up though.

I'd want to do some more thorough measurements to make sure this gives a speedup as expected. E.g. run the whole suite, comparing Mocha vs. Node.js built-in runner vs. Node.js built-in runner without concurrency, more than one time.

More experimentation needed. And we'd want to port the whole suite away from Mocha, not just WPTs. Although obviously speeding up WPT execution time is highly impactful.

[domenic]

Potential regressions in test-running DX:

• --test-name-pattern needing to come before filenames is hostile to npm scripts nodejs/node#51384
• Test runner: spurious "Promise resolution is still pending but the event loop has already resolved" when a callback tests fails nodejs/node#51381
• Some way of not displaying skipped or filtered tests in the spec test reporter nodejs/node#51383

[domenic]

Something about the partially-passing web platform tests is not working. They all display the "Hey, did you fix a bug?" unexpected passing test error.