Add a WebAssembly build to release

[kripken]

Simply build wasm-opt with Emscripten and bundle that up.

Example build:

https://github.com/kripken/binaryen/releases/tag/wasm-build-1

Specifically

binaryen-wasm-build-1-wasm.tar.gz

Only 1.72 MB, as it's just wasm-opt and not any other tool, so it is
much smaller than our other targets. Perhaps we will add more of the
tools later as needed (wasm-metadce, wasm-split, etc.).

Also update the readme regarding which toolchains use us as a library, that I
noticed while editing it to add the release platforms.

[kripken]

(context: #6334 (comment))

[sbc100]

I think you can drop in this repo itself.

[sbc100]

What is the min version of node needed to run the resulting code? Perhaps we should mention/document that somewhere? Perhaps the filename should binaryen-node18 (or something like that) to reflect the way it needs to be run?

[kripken]

I did mention that in the README docs added in this PR. It is Node 18.

Interesting idea about putting it in the name... but I think that might seem odd, as it's 18+. That is, I worry someone might have node 22 and think they need another build.

[sbc100]

How about at least calling to -node then.. since it can't run on anything else.

[sbc100]

Calling it just -wasm is little misleading as it might suggest that all you need is a wasm engine to run it.

[kripken]

Well, it should actually run on deno and bun as well - they are all working to support node APIs now. I didn't test them though. Also, this build is not actually done with ENVIRONMENT=node, which means it can run on the web too.

I get what you're saying about "wasm" being inaccurate but I feel "node" is inaccurate as well. These are basically generic js+wasm builds, or as generic as I can make them. I feel "wasm" is the more forward looking name as they are 95% wasm, and may some day become 100%.

[sbc100]

But the intended audience for this build is purely command line folks who will need to use node to run it right?

If somebody wants to run binaryen on the web then binaryen.js is a much better choice, right?

I suggest we do build with -sENVIRONMENT=node to make this intent clear (at least for now).

[kripken]

Interesting. I hadn't thought of it that way.

I'm not sure ENVIRONMENT=node helps though as this isn't an assertions build, so there won't be a nice clear error message in another environment. I'd also prefer not to limit experimentation here, as experimentation is really the goal - maybe we'll find uses in the browser. E.g. the binaryen.js build uses the JS API, while this build uses the commandline API - maybe replicating commandline workflows would be simpler with it.

But the more I think on it the more I agree with your larger point about the name, so I renamed it to node now and added some docs to clarify the purpose and status. What do you think?

[sbc100]

I get where you are coming from too. Perhaps we can change this in the future but I like the its explicit for now.

[kripken]

I added a passing test that verifies we can round-trip a wat file.