wasm-opt for WASIp2

Over in https://github.com/llvm/llvm-project/issues/147201, @singleaccretion mentioned that they can't use wasm opt:

Not all scenarios can (or want) to use wasm-opt. E. g. we don't use it by default because it can alter function indices. All WASMp2-targeting code doesn't use it (and can't, currently at least). So that's the main motivation (along with the fact that if we were say to use wasm-opt for this small optimization only, it would be at least an order of magnitude slower than if done in the linker [in terms of this optimization's isolated cost]).

I definitely get the desire to avoid wasm-opt for transforms that are required for correctness rather than optimizations (we have the same principle in Emscripten), but also it's still very nice to have for optimizations. And Binaryen tries to be useful across a lot of different wasm toolchains and use cases, so it made me curious about what the requirements of this scenario are ("all WASIp2-targeting code" sounds like a pretty broadly used use case!). It might make sense to have a mode or feature in Binaryen that could make it work here.

@singleaccretion can you maybe say a bit more about what the problems/requirements are for the use case?

Start by reading the linked LLVM issue and the discussion here to identify the WASIp2 requirements and why wasm-opt is currently unsuitable. No source files or tests are named; the work is ready only once those requirements produce a clearly scoped Binaryen mode or feature with agreed validation criteria.