wasip2 target should not conditionally feature gate stdlib APIs

This was introduced in https://github.com/rust-lang/rust/pull/119616 (cc @rylev)

Currently, any crate using std::os::wasi stuff needs to add a #![feature(wasip2)] if it is to be compiled with --target=wasm32-wasip2. This is due to this line:

https://github.com/rust-lang/rust/blob/0307e401c26699656ae08e3809e7d272f5c103f4/library/std/src/os/wasi/mod.rs#L32

This puts library authors targeting stable wasm stuff in an annoying situation of needing to add a feature gate to support downstream users who wish to use unstable wasm stuff (see https://github.com/servo/rust-url/pull/960). This isn't really how feature gates should work: the entity using the feature should be the one opting in. I don't think any of the benefits of feature gates apply if every wasi-using dep in the ecosystem just slaps on a #![cfg_attr(all(target_os = "wasi", target_env = "p2"), feature(wasip2))], which seems likely here.

A somewhat legitimate reason I could see for having such a feature is if the wasip2 target is stable, but certain stdlib things are unstable under that target. It still has the same problems, and I'd argue a target with specially unstable stdlib APIs should not be considered stable, but at least there appears to be a meaningful thing that the stdlib feature gate is gating.

However, it appears to me that wasip2 is just unstable: what's the purpose of gating the stdlib API? If the goal is to gate the target, why not require -Zunstable-options as we do for other CLI-level unstable things?

Start at library/std/src/os/wasi/mod.rs:32 and read the behavior introduced by rust-lang/rust#119616, then trace how the wasip2 target currently triggers the feature requirement. Resolve whether the target or the std::os::wasi APIs should be gated, and verify the chosen policy no longer imposes the reported downstream opt-in.