Deliver stream/future dropped events even when not reading/writing

[lukewagner]

This PR fixes another case where Wasmtime delivers DROPPED results more-promptly than the spec Python definitions and probably Wasmtime is (mostly, see below) right. Specifically, if a readable or writable end of a stream or future is dropped while the other end is in a waitable set but idle (i.e., there is no {stream,future}.{read,write} in progress), it seems like a ({STREAM,FUTURE}_{READ,WRITE}, DROPPED) event should be delivered to the waitable set, but currently the spec won't deliver anything until the next {stream,future}.{read,write}. (Before #719, this was was less obvious and hard to fix, but with #719 it's easy to spot and fix, so this PR is based on #719.)

After updating the spec in this PR and writing a bunch of WAST tests to cover the interesting cases, there is one interesting remaining case where I think Wasmtime's current behavior isn't what we want to specify, but it's worth checking: after one of these DROPPED-during-idle events is delivered to an end, it seems like that end should transition to the DONE state, in which case the only valid operation on the end is {stream,future}.drop-{readable,writable} and other built-ins trap (just like when DROPPED is received while not idle). IIUC, Wasmtime doesn't change the state to DONE and this shows up in the last 6 failing cases at the very end of test/async/idle-drop.wast. @alexcrichton @dicej lmkwyt though

[alexcrichton]

Going over the failing tests here, those all look like bugs in wasmtime to me, yeah

[dicej]

I'll work on getting the new tests passing.

[lukewagner]

Great! I'll fold these tweaks/tests into #719.