Wasm operates using a safestack model. Safe stack operations (register spilling/restores) are saved on the native stack, while stack arrays (or any stack var you take a pointer to) lives in the so-called unsafe stack, which is one of the regions in wasm's linear memory. The wasm linker unfortunately hardcodes the unsafe stack to 64k. But Hunspell seems to perform a lot of pointer math on the stack --- this is optimized well by clang when optimizations are enabled, but causes an OOM in the unsafe stack on non-optimized builds. We need to modify wasmboxed hunspell to use a larger unsafe stack.

This bug only fixes the issue for the wasm2c wasmboxed library, as we will be moving away from lucet shortly. See bug 1720828

Depends on D120570

Note we are also changing Wasm's compilation to put the stack before globals. This because this OOM causes a buffer underflow resulting in corription of C globals. Note this is not a security bug as all this occurs inside the wasm linear memory. However, trapping during in OOM is preferable. Putting the stack before globals will result in OOM manifesting as an error (except in the rare case where we are using all 4GB of Wasm's linear memory) as the underflow will wrap to the end of the linear memory.

https://hg.mozilla.org/mozilla-central/rev/147efa2b48f4
https://hg.mozilla.org/mozilla-central/rev/5c7c771620da