feat: Let Binaryen encode our memory init more efficiently

[geraintluff]

AssemblyScript produces a bunch of small data chunks. Binaryen can split up large chunks to represent them in a compact way, but not combine them.

This change checks whether Binaryen will be doing any optimisation at all, and combines all the MemorySegments into one big segment.

Here's a comparison of the bootstrapped AssemblyScript compiler itself, with and without the change:

file	bootstrap size (before)	bootstrap size (with changes)	delta
assemblyscript.debug.wasm	1783641	1785335	+0.10%
assemblyscript.debug.wasm.gz	379084	379560	+0.13%
assemblyscript.release.wasm	918047	916063	-0.22%
assemblyscript.release.wasm.gz	224686	223556	-0.50%

Since this patch adds functionality, it increases the code size of the debug build, but the release build is still smaller due to the repacking.

It's a small improvement, and on my other projects I'm only seeing a ~1% change but 🤷.

• I've read the contributing guidelines
• I've added my name and email to the NOTICE file

[geraintluff]

Oh, and obviously it fails a bunch of release-build fixture tests, because it's packing the data differently. 😅

[dcodeIO]

Won't this essentially compress alignment away, say for example when we want 4-byte alignment for reasonably performant 32-bit memory accesses?

[geraintluff]

@dcodeIO This doesn't change the memory layout at all, only how it's serialised into WASM/WAT.

The title is probably misleading, sorry! Here's an example of the issue - it will take less space to serialise those as a single block of \01\00\01\01\01 (note the inserted zero), instead of four separate (data ...)s.

[HerrCai0907]

My biggest concern is this feature may OOM the building machine when the wasm is large. I remember there are a PR (maybe not merged) to don't create a real JS buffer during compilation when the data is all-zero to reduce the memory cost.

e.g. memory.data(large_number)

[geraintluff]

My biggest concern is this feature may OOM the building machine when the wasm is large.

@HerrCai0907 Excellent point. I'll convert this back to draft, and then re-open when I have something incremental which avoids this problem.