Give future.write flat params (like async imports)

[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.

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.