Drop of http::Client::send Future causes trap, and related tribulations

[pchickey]

If you drop the http::Client::send future, e.g. with a FutureExt::timeout here c184831 , wasmtime will trap because the parent resourceFutureIncomingResponse is dropped before its child Pollable.

One way to fix that is to replace the Future rust generates from the async fn with a struct of our own with the field ordering such that the child Pollable drops first, e.g. https://github.com/yoshuawuyts/wstd/blob/pch/scratchpad_reactor_refactors/src/http/client.rs#L33-L46 https://github.com/yoshuawuyts/wstd/blob/pch/scratchpad_reactor_refactors/src/http/client.rs#L83-L115

This restructuring motivated me to make Reactor::wait_for take a &Pollable instead of take ownership e.g. c740f1b which in turn creates more problems - now a simple task::sleep will panic.

The plan currently is we need to refactor the executor to resolve the architectural problems this revealed.

[pchickey]

This has been worked around for now as part of rewriting things in terms of AsyncPollable in #35. The underlying issue that wasmtime (and the CM in general) is stricter than necessary about trapping when a parent is dropped before a child still exists, and I'll work on switching wasmtime and CM over to a child-tombstone model on parent drop, where it only traps if a child is used after the parent is dropped in another context.