support wasm32-unknown-unknown with threads, fs, and timer

[xusd320]

I successfully made tokio work with fs, threads and timer on browser, compile target is wasm32-unknown-unknown. See the example:

https://github.com/utooland/tokio-on-browser.git

Infrastructures used to support features:

• forked tokio: https://github.com/utooland/tokio
• fs: https://github.com/utooland/tokio-fs-ext , based on browser's OPFS
• threads: https://github.com/utooland/wasm_thread , a forked version of https://crates.io/crates/wasm_thread
• timer: https://github.com/utooland/wasmtimer-rs , a forked version of https://crates.io/crates/wasmtimer

I'm not sure that could these features could be considered supported by upstream? I can help maintain these features. Current implements is not elegant enough, I will refactor it to be better if there features are acceptable for upstream.

[xusd320]

Ref #7510

[afc163]

LGTM

[Darksonn]

I'm not so familiar with wasm, but Tokio's existing wasm support focused on wasi v1, which IMO is a completely separate platform from browsers, and now there is also wasi v2 and something called wasmedge. Even within browsers there is web workers and non-web-worker, which are also very different. I get the impression that wasm is really a large collection of many different platforms, all of them so fundamentally different that they all require their own support directly in Tokio. We simply don't have the bandwidth to support so many platforms in Tokio.

[xusd320]

I'm not so familiar with wasm, but Tokio's existing wasm support focused on wasi v1, which IMO is a completely separate platform from browsers, and now there is also wasi v2 and something called wasmedge. Even within browsers there is web workers and non-web-worker, which are also very different. I get the impression that wasm is really a large collection of many different platforms, all of them so fundamentally different that they all require their own support directly in Tokio. We simply don't have the bandwidth to support so many platforms in Tokio.

I see. How about make a mechanism to allow tokio use a custom runtime builder? Then tokio upstream can only maintain the unix/windows support by mainline, but third part users can use a self-defined builder to build a tokio runtime. The scenario is that we are porting some programs based on tokio from native to wasm, and there programs need multi threads support. But tokio tasks can only be executed in a tokio runtime context.