Spec test updates

[bvisness]

Adds core and JS API spec tests for recent updates as described in #80.

We needed fewer updates than I had originally thought. See the individual commits. Tests I did not have to write include:

• Offsets outside of i32 range for memory32 (Restricting offsets to match the index type #76) (this was already present in the spec interpreter and spec tests, just not in the actual spec)
• Tests for call_indirect on table64 (@sbc100 already added these)

Beyond adding tests for memory64, I also took the opportunity to significantly enhance the memory import tests, since multi-memory is now standard.

Resolves #80.

[sbc100]

Fantastic, thanks for working on this Ben!

I wonder if we should split out the js-tests into a separate PR since they seem logically separate to me (and the imports.wast change includes other misc changes for multi-memory)?

[bvisness]

Converting to draft while I update the spec tests to reflect the change to "address type".

📣 ATTENTION! 📣 This is your last chance to bikeshed the name of the parameter used in memory and table descriptors! It used to be "index", but I changed it to "addressType" in #90 after discussion in #67. If you would prefer it to be "address" or something else, please let me know now so I can update the spec and tests! (cc @sbc100, @backes, @rossberg, and @tlively, who all participated in #67 but did not express an opinion there.)

[backes]

"addressType" sounds good to me. This PR is not updated for that yet, right?

[bvisness]

@eqrion has pointed out to me that WebAssembly.Global uses "value" for the global's value type, and WebAssembly.Table uses "element" for the element type. Given that precedent, I'm now strongly feeling like it should be "address" instead of "addressType". Sorry I didn't think of this sooner, but hopefully it's no trouble for people to support once I get it in the spec.

[sbc100]

@eqrion has pointed out to me that WebAssembly.Global uses "value" for the global's value type, and WebAssembly.Table uses "element" for the element type. Given that precedent, I'm now strongly feeling like it should be "address" instead of "addressType". Sorry I didn't think of this sooner, but hopefully it's no trouble for people to support once I get it in the spec.

addressType seems like the most explicit. Its more verbose but probably better to be explicit, right?

[tlively]

No strong preference between address and addressType. addressType seems nicer in isolation, but I agree that it is good to keep the naming scheme for similar properties consistent across different parts of the API.

[eqrion]

I would also prefer addressType if it weren't for the fact that the JS-API already has a strong precedent for using the shorter name. I personally think it would have been better for globals to take valueType instead of value, and ditto for tables. But they don't so I think we should use address to match them.

[bvisness]

Given the prior positive reviews, and no dissent on the change to address, I'm going to go ahead and merge this.