Don't generate bindings with a synthetic package

[alexcrichton]

This commit addresses an issue in Rust nightly with the Rust standard library. Notably what's happening is that the wasi crate is using a synthetic world/package called rust:wasi/bindings to generate bindings. This world includes wasi:cli/imports and wasi:http/imports. What's happening is that the Rust standard library is using one version of the wasi crate with one version of WASI bindings, but user crates might use something different. This fails to link because rust:wasi/bindings is asserted to be the same no matter what and there's two different wasi crate versions feeding into this which cause conflicts.

The fix in this commit is to skip using rust:wasi as a package and generate bindings directly from WASI packages themselves. These bindings correctly have versions in them and are versioned appropriately so there's no clash and merging proceeds as expected.

This required moving the bindings for wasi:http/imports into the generation of bindings for wasi:http/proxy, but that doesn't actually change the structure of the crate just how the generated bindings work out.

[alexcrichton]

Courtesy of @pchickey this PR is solving this current breakage on nightly:

$ cat Cargo.toml
[package]
name = "wit-component-merge-repro"
version = "0.1.0"
edition = "2024"

[dependencies]
wasi = "=0.14.0"
$ cat src/main.rs
fn main() {
    let now = wasi::clocks::monotonic_clock::now();
    println!("Hello, world {now}!");
}
$ cargo +nightly-2025-09-04 build --target wasm32-wasip2
error: linking with `wasm-component-ld` failed: exit status: 1
  |
  = note:  "wasm-component-ld" "-flavor" "wasm" "--export" "__main_void" "--export" "cabi_realloc" "-z" "stack-size=1048576" "--stack-first" "--allow-undefined" "--no-demangle" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained/crt1-command.o" "<2 object files omitted>" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/libpanic_abort-*.rlib" "/Users/p.hickey/src/wit-component-merge-repro/target/wasm32-wasip2/debug/deps/{libwasi-45fb34f8a145884a,libwit_bindgen_rt-34790fea67077ff3,libbitflags-04c7d363c51124f5}.rlib" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/{libstd-*,libwasi-*,libwasi-*,libwit_bindgen-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*}.rlib" "-l" "c" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/{librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-l" "wit_bindgen_cabi_realloc0_37_0" "-L" "/Users/p.hickey/src/wit-component-merge-repro/target/wasm32-wasip2/debug/build/wit-bindgen-rt-032c5c722475ea60/out" "-L" "<sysroot>/lib/rustlib/wasm32-wasip2/lib/self-contained" "-o" "/Users/p.hickey/src/wit-component-merge-repro/target/wasm32-wasip2/debug/deps/wit_component_merge_repro-3101829626d3e605.wasm" "--gc-sections" "-O0"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: error: failed to parse core wasm for componentization

          Caused by:
              0: updating metadata for section component-type:wit-bindgen:0.45.0:rust:wasi:bindings:encoded worldrust-wasi-from-crates-io-in-libstd
              1: failed to merge WIT package sets together
              2: failed to merge package `rust:wasi` into existing copy
              3: failed to merge world `bindings`
              4: import `wasi:io/poll@0.2.4` not found in target world


error: could not compile `wit-component-merge-repro` (bin "wit-component-merge-repro") due to 1 previous error

[pchickey]

I'm concerned we now have two different Resource structs defined - the wasi:http/types and outgoing-handler interfaces used to use the one now in imports, but now uses this one. They have identical text, but will we run into problems where the types arent actually equal?