add stream.forward and future.forward builtins (alternative definition)

[lukewagner]

This PR is based on the great work in #709, but reformulates the definition of {stream,future}.forward to avoid the dynamic forward field/indirection on streams/futures that was a bit invasive and complex to think through. Instead the definition in this PR mutates the relevant readable and writable ends in-place which ends up being a lot simpler and, iiuc, closer to what an implementation would actually do. To enable this "just mutate the ends" approach in the second commit, the first commit refactors the definition of streams/futures so that streams/futures always have ends (even when the host is the reader and/or writer). This refactoring was a bit invasive, so it felt bigger than something I could reasonably ask for in a review comment in #709. But it ended up becoming a pretty nice simplification for futures/streams overall that reduced lines of code, removed some special cases, and highlighted a spec bug where DROPPED wasn't delivered as eagerly as it should have been (included as a WAST test in the refactoring commit that Wasmtime passes).

The only actual behavioral difference in this PR vs. #709 that I'm aware of is that there is no trap in the "self-loop" corner case (where the readable and writable ends passed to {stream,future}.forward are both attached to the same stream/future); it's just a no-op (the stream/future is no longer alive since both of its ends were just dropped). But if anyone has any good reasons why it should trap, happy to discuss.

The refactoring/simplification commit is nice, but touches a lot, so if you're only interested in {stream,future}.forward, I'd suggest only looking at the second commit. The second commit also includes a bunch of WAST tests for the various interesting semantic cases.

PTAL @rvolosatovs