[Part 2] Remove submodules, update tooling and samples

[iBicha]

Follow up to #14 (contains its changes, because it branches from it)
Diff iBicha/wasm2brs@feature/update-dependencies...iBicha:wasm2brs:feature/remove-submodules

• Removed wabt and binaryen

  • They are fairly heavy, there was no need to compile the whole codebase every time.
  • Instead they are replaced with released versions
  • As a result, building things can be very fast even if entire build folder is deleted

• Updated docker

  • Ubuntu 24.04 LTS
  • Install tools (emscripten, wabt, binaryen, wasi-sdk, wasmer, rust support)

• Update samples

  • cmake: builds and runs
  • doom: builds to wasm, but there's an error with wasm-opt
Assertion failed: startMap.count(span.start) == 0 (/src/src/wasm/wasm-debug.cpp: add: 415)
    • Tried wasm-opt from binaryen v115, and I got hit by Function $137 had 324 labels - Label limit reached so something has changed in how wasm-sdk generates code I assume.
  • files: builds and runs
  • javascript: builds and runs
    • Updated duktape to 2.7.0 - this is why the PR has 12k changes, but it's all duktape
    • There was an issue with using wasi-sdk, build is now done with emscripten-sdk
  • mandelbrot: wasm-ld: error: /tmp/mandelbrot-20f571.o: undefined symbol: memset
    • A libc issue?
  • rust: builds and runs

[iBicha]

@TrevorSundberg can you advise? I've taken steps to try and update the repo, but I've broken a few things in the process.
I don't know if the best course of action is to

• Try to bisect which version of wabt and/or wasi SDK would still work with the current state or wasm2brs, or
• Try to figure out if there's a way to configure wasi SDK to make it build things "differently", or
• Try to update the test suite and go from there (but there's disabled tests, tests that don't make sense for BRS I assume, unimplemented features, etc), or
• Try to debug duktape brs code and vs wasm/wat code and see where things are disconnected, or
• Something else?

I'm fairly new to wasm ecosystem and I haven't spent enough time on it, so any help is appreciated, thanks

[TrevorSundberg]

Let me pull what you have tomorrow and then advise from there. I'm in Taiwan right working hard on my game (in Unity :P) and will get back to you when I get some time!

[iBicha]

I made some progress on the topic; I did go the route of the tests at first, so I pulled the test suite, and followed closely the diff with the fork WebAssembly/testsuite@main...MotleyCoderDev:testsuite:master to figure out what broke - but most things didn't break according to the test.

I went back to the older version, fixed what was broken and built the javascript sample into a .wasm, and then brought the wasm into the newer version of wasm2brs. Then it worked!

I realized later that something drastically changed between wasi-sdk versions, because not only the javascript wasm was no longer running correctly, but it was also about 8x larger in size (about 400kb to about 3 mb) and that was normal.

I was going to investigate this path, then I remembered that even the latest wasi-sdk doesn't support exceptions, which is what I'm trying to achieve in the first place. So I dropped that, and tried to build using emscripten. Lo and behold, the js sample is working again, and at a reasonable size again.

With that in mind, I think this PR is fairly ready.

Which opened up room for me to start looking into #16