Split memory64 JS API tests into separate files

[dschuff]

Part of #1950, similarly to what was done with the memory64 core tests

[dschuff]

Alternatively this could go into a separate directory to more strictly mirror the core tests...

[sbc100]

Is there any other proposal that did it this way for the js-api tests? Why single out memory64?

[dschuff]

If there are others, it would make sense to do those too. I just started with memory64 because there's an interop proposal for memory64, so this is just to make it easier to specify which tests belong to that.

[dschuff]

@sbc100 and/or @Ms2ger, you have any opinions about this?

[Ms2ger]

I'm mildly negative about it - the design of testharness.js should be sufficient to track subtests if needed, but I won't block if you're convinced this is necessary.

[sbc100]

Same here, I'm kind of neutral, but if its needed to the interop 26 proposal then so be it!

[dschuff]

The interop proposal is the most-direct cause of me wanting to work on this proposal in particular, but
it does seem like it would be good if the JS tests mirrored the organization of the core tests (see #1950), and more generally WPT's WEB_FEATURES.yml mechanism for associating tests with features only works at file granularity.
I'll merge this for now, but can you maybe say more about the testharness.js? You just mean that there's a mechanism to group tests into groups or subtests?