Add `Send` to `p2::WasiHttpHooks` trait (#12793)

This means that the trait object `&mut dyn p2::WasiHttpHooks` is itself
`Send` which is generally necessary for `async` operation.

Refactor `wasi:http` headers' host representation (#12754)

* Refactor `wasi:http` headers' host representation

This commit is a follow-on/extension of #12748 and extends the changes
made for WASIp2

Refactor `wasi:http` headers' host representation (#12754)

* Refactor `wasi:http` headers' host representation

This commit is a follow-on/extension of #12748 and extends the changes
made for WASIp2 headers in #12652 to the WASIp3 implementation as well.
This is done through a number of refactorings to make the WASIp2 and
WASIp3 implementations more similar in terms of how they represent
headers. Changes here are:

* `FieldMap` now has its own dedicated module at the crate root instead
of intermingling with other WASIp2 types.
* `FieldMap` is now internally-`Arc`'d and is cheaply clonable.
`FieldMap` itself now tracks whether it's mutable or immutable (WASI
semantics) and doesn't need different wrappers in WASIp2 and WASIp3.
* Creation of an immutable `FieldMap` can be done without needing a size
limit. Flagging a `FieldMap` as mutable, however, requires a size limit.
* `FieldMap::set` was added to be a bit more efficient w.r.t. clones.
* `FieldMapError` is a new error type that covers all of the possible
error modes of operating with a `FieldMap`. Conversions from this to
WASIp{2,3} `header-error` types are now implemented as well.
* WASIp2 now flags `header-error` as a trappable-error-type, allowing
the use of `?` in implementing header functions (like WASIp3).
* Much of WASIp2's header implementation was refactored with `?`, moving
methods around, shuffling where headers are made vs `FieldMap`, some
minor idioms, etc.
* WASIp3 no longer uses `MaybeMutable` for headers and instead uses
`FieldMap` directly.

cc #12674

* Clippy warnings

show more ...

Refactor WASIp2 `wasi:http` implementation (#12748)

* Sequester WASIp2 in `wasmtime-wasi-http` to a module

This mirrors the `wasmtime-wasi` crate's organization where there's a
`p2` module and a `

Refactor WASIp2 `wasi:http` implementation (#12748)

* Sequester WASIp2 in `wasmtime-wasi-http` to a module

This mirrors the `wasmtime-wasi` crate's organization where there's a
`p2` module and a `p3` module at the top level.

* Refactor WASIp2 `wasi:http` implementation

This commit reorganizes and refactors the WASIp2 implementation of
`wasi:http` to look more like other `wasmtime-wasi`-style interfaces.
Specifically the old `WasiHttpImpl<T>` structure is removed in favor of
as `WasiHttpCtxView<'_>` type that is used to implement
bindgen-generated `Host` traits. This necessitated reorganizing the
methods of the previous `WasiHttpView` trait like so:

* The `WasiHttpView` trait is renamed to `WasiHttpHooks` to make space
for a new `WasiHttpView` which behaves like `WasiView`, for example.

* The `ctx` and `table` methods of `WasiHttpHooks` were removed since
they'll be fields in `WasiHttpCtxView`.

* Helper methods for WASIp2 were moved to methods on `WasiHttpCtxView`
instead of default methods on `WasiHttpHooks`.

With these changes in place the WASIp3 organization was also updated
slightly as well. Notably WASIp3 now contains a reference to the crate's
`WasiHttpCtx` structure (which has field limits for example). WASIp3's
previous `WasiHttpCtx` trait is now renamed to `WasiHttpHooks` as well.
This means that there are two `WasiHttpHooks` traits right now, one for
WASIp2 and one for WASIp3. In the future I would like to unify these two
but that will require some more work around the default `send_request`.

A final note here is that the `WasiHttpHooks` trait previously, and
continues to be, optional for embedders to implement. Default functions
are provided as `wasmtime_wasi_http::{p2, p3}::default_hooks`.
Additionally there's a `Default for &mut dyn WasiHttpHooks`
implementation, too.

With all that outlined: the motivation for this change is to bring the
WASIp2 and WASIp3 implementations of `wasi:http` closer together. This
is inspired by refactorings I was doing for #12674 to apply the same
header limitations for WASIp3 as is done for WASIp2. Prior to this
change there were a number of differences such as WASIp3 not having
`crate::WasiHttpCtx` around, WASIp2 having a different organization of
structures/borrows, etc. The goal is to bring the two implementations
closer in line with each other to make refactoring across them more
consistent and easier.

* Make `WasiHttp` in WASIp2 public

* Fix some conditional build

* Fix some doctests

* Fix configured build

* Fixup documentation

show more ...