Tweak future ABI to make sense independently of streams

[lukewagner]

This PR is a "part 2" of #520, allowing future.write to take up to MAX_FLAT_ASYNC_PARAMS (=4) flat params before resorting to an i32 pointer. For symmetry with async lowering, future.read is changed to take zero parameters if there is no element type.(Update: removed this part of the change)

Working through these changes in the spec highlighted the fact that framing future as "a stream that mostly takes 1 element" is too much of a stretch and requires too many hacks that overall add more confusion than simplification. Based on this, this PR decouples future from stream so that futures make sense on their own. Concretely, this results in the following tweaks to the CABI:

• the {stream,future}.close-{readable,writable} built-ins are renamed to {stream,future}.drop-{readable,writable} both for symmetry with { resource.drop, subtask.drop } and because "close" is a stream-specific verb. The CLOSED result code is accordingly renamed DROPPED.
• There is no "number of elements written" packed in the high 28 bits of the future.{read,write} results.
• On successful copy, future.{read,write} return COMPLETED instead of CLOSED (which, as noted above, was renamed to DROPPED, making it especially "wrong" as the result code).
• When a future is "done" (by a COMPLETED read/write or by the writable end receiving DROPPED), the only valid operation is future.drop-{readable,writable}. future.{read,write} or lifting traps.
• Because there's no great reason for streams to be more permissive than futures in this regard, streams are also given a "done" state with the same trapping rules as futures, but the stream "done" state is only set when DROPPED is received.

[lukewagner]

I updated the PR to remove special case where future.write takes MAX_FLAT_ASYNC_PARAMS and future.read has zero params when there is no T, keeping future.{read,write} like stream.{read,write} in always taking a single i32 pointer. The other 5 tweaks in the bulleted list above are kept (along with the spec refactoring which splits out futures), which still seem to like an improvement, but, after some experimentation, the implementation complexity of handling flat-args for futures doesn't seem worth it.