Experimental wasm multithreaded hotpatch

[qouteall]

Implement hotpatching for Wasm multithreading.

• The passive data segment itself doesn't tell offset in memory. Parse __wasm_init_memory function instructions to know the in-linear-memory offset of passive data segments.
• Generate a fake stub Wasm object file for TLS symbols to make linker not error.
• Workaround to avoid wasm-bindgen GC-out the passive data segments
• Add a command line argument --disable-js-glue-shim to avoid wrongly loading Wasm in web worker.
• Some liner argument tweaking.
• In multithreading, patch binary doesn't clear start section to ensure its data segments initialize.
• Wasm multi-threaded dynamic linking: (behind crate feature experimental_wasm_multithreading_support)
  • Each thread need to call init_hotpatch_for_current_thread on startup to initialize
  • Internally use BroadcastChannel to communicate. (This is less intrusive than controlling web worker message callback or requring passing a MessageChannel,)
  • Allocate auto-increment thread id for tracking
  • Use global state protected by spinlock (use spinlock because main thread cannot block using i32.wait
  • When growing memory, pase dylink.0 section to know data size to reduce memory waste (TODO this can also be applied to single-threaded hotpatching)
• In assets::find_wasm_symbol_offsets I removed hardcoded offset (doesn't work in my case) and uses passive segment offset obtained by parsing __wasm_memory_init. As I tested, in --release it still have function name during asset processing.

Example to test: https://github.com/qouteall/RustWasmMultithreadingHotswapExample

Other things:

• Currently wasm splitting doesn't work with multithreading.
• Building that example has "Failed to minify js. Falling back to non-minified: failed to bundle javascript with swc" because it has own js to initialize which references the JS file generated by wasm-bindgen, but bundler cannot find that file. This does not affect functionality in dev.
• The hotpatched crate's own data address and TLS address are not stable after hotpatching. As I tested, that issue already exists in single-threaded wasm hotpatch and windows native hotpatch. Subsecond hotpatch doesn't preserve mutable global variable address in hotpatched crate. #5237