Plan for GC and beyond

The function-references and gc proposals are going to be merged into the spec soon (as well as the "v4" revision of the exception-handling proposal, which we don't support yet). It could be good to talk about our plan for supporting these features in WABT. I think there's a few options to put on the table:

• We work on the current best-effort basis to update our exception-handling support and finish the implementation of function-references and gc (in the binary/text readers/writers, the interpreter, and wasm2c). I'm not sure who has a ton of spare cycles for this, but if there is continued interest in WABT, I and other contributors will probably eventually make it happen. Could take a long time though, and I'm a little nervous about losing community trust/interest if we allow WABT to fall behind the living spec for too long.
• We try to (re-)increase investment of engineering resources in WABT by some of the companies who use it. Based on conversations at the CG meeting, this seems like a bit of a long shot, but maybe I misread the situation or there is something these companies would want from us that we could provide. (E.g. how to make a persuasive case for Google and Mozilla to devote more engineering resources or to find a way to pay Igalia or others to start contributing more again.)
• We deprecate most of the WABT tools except for wasm2c, which we'd port to run in binaryen. An upside is that binaryen attracts a lot of investment/velocity and seems to be Google's focus right now in terms of non-browser Wasm tools, and wasm2c would get to ride its coattails; downside is that binaryen isn't really intended (as I understand it) as a spec-conforming implementation of a Wasm binary/text reader/writer + validator/interpreter, given its IR that is slightly different from Wasm. (And, smaller point, binaryen currently seems to be much slower than WABT at some operations like a wasm-merge.) So the community would lose that part of WABT's benefits.
• We replace the internals of WABT with the Bytecode Alliance's Rust wasm-tools project, and port wasm2c to run in wasm-tools. Upside is that this is also a heavily depended-on building block from the BA folks and a newer Rust codebase that also passes the spec tests, and it might be worthwhile to combine our efforts (aiui there are minor differences, e.g. I think wasm-tools can't currently write the folded text format which seems minor and probably addressable); downside is that this would be a pretty avulsive change (moving to Rust among other things) and would really need to have buy-in, might lose a lot of the current contributors, and would take significant investment to pull off. (Edit: and I also don't know how performance compares with WABT on huge modules.)

I don't think anything is forcing us to make a decision here, but tentatively I'd rather make one than sort of avoid it.

Review the function-references, gc, and exception-handling proposals alongside WABT's binary/text readers and writers, interpreter, and wasm2c components. Compare the listed paths involving Binaryen and wasm-tools, then document a maintainers' and community decision for keeping WABT aligned with the living WebAssembly spec.