Refactor build-js.sh into a Makefile

[kripken]

This cleans up and refactors the binaryen.js build script to be
a proper Makefile. Aside from cleanliness, the main benefits
are:

• Allows parallel compilation of source files with make -jX.
• Switches the build to wasm, and not js, as it turns out
  the wasm backend is broken on js builds, so this works around
  that until we solve it. However, maybe we just want the build
  to be wasm anyhow? Binaryen.js builds with wasm2js fail #2446

[kripken]

cc @dcodeIO

[dcodeIO]

Compiling to Wasm exclusively sounds good to me. Two questions:

• I remember that browser VMs, unlike node, have relatively tight size constrains for synchronous compilation, so I wonder if disabling async compilation might break binaryen.js in browsers?
• Providing (only) a Makefile makes me worry about Windows support. Or does emmake take care of this?

[kripken]

• True, running in browsers will be an issue without async compilation. We should provide an async API for starting up binaryen.js, I guess, like Binaryen.then() perhaps? I don't remember what the best practices are for such things. But yeah, given that maybe we should not land this just now.
• I think the old script was bash-only, so it also probably didn't work on windows?

[dcodeIO]

I guess, like Binaryen.then() perhaps? I don't remember what the best practices are for such things. But yeah, given that maybe we should not land this just now

I remember the Binaryen.ready promise idea in #1381, similar to Wabt's ready promise. One could then

if (!Binaryen.isReady) await Binaryen.ready;
...

I think the old script was bash-only, so it also probably didn't work on windows?

Git for Windows includes Git Bash, which makes a bash file quite convenient. Is there maybe a way to make this a cmake task, conditionally creating a VS project? Would be similar since one needs cmake anyway to build parts of Binaryen. I don't know much about this, unfortunately

[kripken]

I see, thanks. Ok, sounds like this PR isn't the right way to go - I'll close this, and open issues for those ideas, which I agree are the right way to go. Not sure I'll have time for them myself, though.