feat(wasm): add support for the stable target wasm32-wasip2

[brooksmtownsend]

Fixes #2294

Depends on servo/rust-url#983

This PR, in order of commits:

• Adds target conditionals to separate the compilation of reqwest in the general wasm32 OS and the wasm32-wasip2 target (which is now a tier 2 target and Rust stable in 1.82)
• Adds .vscode to the .gitignore (I can remove this if it's undesired)
• Adds wasm32-wasip2 implementations for reqwest so that you can compile WebAssembly components and make outgoing requests that compile down to wasi:http bindings
  - This commit also adds a patch for crates.io that depends on fix: support wasm32-wasip2 on the stable channel servo/rust-url#983, which is why this PR is a draft. There is no significant functionality change upstream to make the wasm32-wasip2 target work for the url crate, just a change to remove an unstable feature flag.
• Adds an example wasm_component to illustrate how this crate can be used in the context of a wasm32-wasip2 program.

I've attempted to bring over the minimal implementations into the wasm32-wasip2 code, e.g. no multipart support, to keep the review focused and simple to start. If any of these need to be added, I'm happy to add follow-up commits after the review.

[brooksmtownsend]

Apologies for letting this go stale here, I haven't had the time to really shore this one up. I think there's a lot of promise in this approach, and I also don't want to overindex on supporting wasi:[email protected] if we could possibly support it using a combination of the stdlib and tokio in this crate.

I think in the shorter term what would make this PR a candidate for review and merging would either be:

1. Integration into the async reqwest using a wasm-compatible async runtime (like tokio)
2. Integration into the blocking reqwest as-is (which I've looked into, and may be more complicated than first meets the eye)

[jlizen]

Integration into the async reqwest using a wasm-compatible async runtime (like tokio)

Something to call out is that at least some tokio features do break on wasm if naively depended on, ref #2509

Specifically, the use of the tokio timer seems to cause issues. You'll see that there is currently conditional compilation to keep wasm platforms from relying on tokio/time and tower/timeout. Just something to keep in mind if trying to pull wasm support into the async client, it'll take some refactoring.

Perhaps I'm lacking context and wasm32-wasip2 and this isn't an issue for that platform, which is cool if so. Anyway still will need to tweak the conditional compilation accordingly.