feat(compiler): Use Binaryen's bulk memory polyfill

[spotandjake]

This replaces our custom bulk memory polyfills to use the binaryen pass implementation.

Notes:

• We no longer test the polyfill behaviour as we are not trying to test binaryen and we don't have a good way of inspecting the wasm output.
• The feature flag must be left on, as the instructions get optimized away, and if it was off, adding the instructions would throw exceptions in binaryen.
• Bulk memory is now supported across the board, so this polyfill is far less important than it was initially. This reduces our maintenance complexity, shifting it over to binaryen.

Closes: #2330

[spotandjake]

I noticed these signatures were slightly wrong previously, we never saw this behaviour because the names ended up coming from the polyfills rather than from the primitives however without correcting this mistake this pr would be breaking if you tried to use named arguments.

[ospencer]

I do think we need some kind of smoke test here. We don't need to test Binaryen's behavior in the sense that we need to make sure that the polyfill is correct, but we do need something that makes sure if those couple lines of code get deleted the test fails.

An idea: parse the finished module and verify that the bulk memory feature isn't on.

[spotandjake]

Made those changes

[ospencer]

And the smoke test?

[spotandjake]

I do think we need some kind of smoke test here. We don't need to test Binaryen's behavior in the sense that we need to make sure that the polyfill is correct, but we do need something that makes sure if those couple lines of code get deleted the test fails.

An idea: parse the finished module and verify that the bulk memory feature isn't on.

~~I don't think that this would be trivial; it would basically be implementing a WASM parser. It could be a little simpler, we could scan the code section for the instruction codes instead of parsing, but we would need to ensure they aren't showing up elsewhere ever do to any other changes, such as in an i32.const, align or any other cases.

If we're really serious about this, we could maybe use binaryen to load the code back in and check it with that, but I don't think that's the most trivial thing either.~~ Nevermind I understand what you mean now.

[spotandjake]

Some tests added.

[spotandjake]

Addressed those comments. I export the Memory.fill and Memory.copy directly so they can never be optimized away.

[ospencer]

Thanks, looks great!