feat(compiler): Cleaner wasm output for low-level wasm types

[ospencer]

This avoids an issue in Binaryen v102 where spurious multivalue types appear because of our use of tuples (by using far fewer tuples).

[phated]

Amazing work 🙏 I think we have 2 follow-ups to this:

1. Please create an issue to add a NEAR smoketest to our CI - you can assign it to me, but it'll block dropping Node 14 support
2. We need to document, or file an issue, or write a fix for binaryen. I'm not sure the best way to track this.

[ospencer]

Smoketest issue is #1160. I'm not really sure how to track the binaryen issue either. Maybe a promise that I'll do it? 😛

I'm really still just trying to provide a good repro for them with binaryen.ml—I have a small Grain program that repros, but I would feel bad submitting that to them.

[ospencer]

Excellent news (in a way, we may have to abandon our stack-hack with tuples)—there's no Binaryen bug at all. They added an optimization that lifts identical code from the arms of ifs and selects, so if you have something like if (...) then tuple_extract(tuple_make(...)) else tuple_extract(tuple_make(...)) that'll get optimized to tuple_extract(if (...) then tuple_make(...) else tuple_make(...), which introduces multivalue types on the if itself. I suppose it gets you slightly smaller wasm output in our case since you'd only need one drop instead of two.

[ospencer]

Called this out over in WebAssembly/binaryen#4526

[peblair]

(a,b)[0] 🙅‍♂️