Similar to #727, but this affects the spec, not just the reference implementation.

After #726 lands, pipeTo() will say to write anything that was read, unless there is a close queued, or the stream is errored/closed.

But we should also handle the case of there being an error in progress. Currently this means an abort is queued, but after #721 things in that area will be more uniform, so we should wait to fix this until that lands.

Probably when we do so we'll want to factor out some writable stream abstract op like WritableStreamCouldWriteSucceed() and use that in write() and in the two branches of pipeTo().

In practice the impact here is not so big: basically it avoids an extra trip to the writer, which will immediately throw away the attempt at writing. I'm not even sure if it's testable.