fixes #5715

In synchronous Writable streams (where the _write cb is called on the
current tick), the 'finish' event (and thus the end() callback) can in
some cases be called before all the write() callbacks are called.

Use a counter, and have stream.Transform rely on the 'prefinish' event
instead of the 'finish' event.

This has zero effect on most streams, but it corrects an edge case and
makes it perform more deterministically, which is a Good Thing.

Since 049903e, an end callback could be called before a write
callback if end() is called before the write is done. This patch
resolves the issue.

In collaboration with @gne

Fixes felixge/node-formidable#209
Fixes #5215

Doing this causes problems:

    z.write(Buffer(0));
    z.end();

Fix by not ending Writable streams while they're still in the process of
writing something.

This vastly reduces the overhead of decodeStrings:false streams,
such as net and http.

Calling end(data) calls write(data).  Doing this after end should
raise a 'write after end' error.

However, because end() calls were previously ignored on already
ended streams, this error was confusingly suppressed, even though the
data never is written, and cannot get to the other side.

This is a re-hash of 5222d19a11ed0e29d207da0e8c9c8e0e3b18ad78, but
without assuming that the data passed to end() is valid, and thus
breaking a bunch of tests.

It's breaking ~22 tests, Needs further investigation.

This reverts commit 5222d19a11ed0e29d207da0e8c9c8e0e3b18ad78.

Calling end(data) calls write(data).  Doing this after end should
raise a 'write after end' error.

However, because end() calls were previously ignored on already
ended streams, this error was confusingly suppressed, even though the
data never is written, and cannot get to the other side.

This handles the fact that stream.Writable inherits from the Stream class,
meaning that it has the legacy pipe() method.  Override that with a pipe()
method that emits an error.

Ensure that Duplex streams ARE still pipe()able, however.

Since the 'readable' flag on streams is sometimes temporary, it's probably
better not to put too much weight on that.  But if something is an instanceof
Writable, rather than of Readable or Duplex, then it's safe to say that
reading from it is the wrong thing to do.

Fix #3647

It seems like a good idea on the face of it, but lowWaterMarks are
actually not useful, and in practice should always be set to zero.

It would be worthwhile for writers if we actually did some kind of
writev() type of thing, but actually this just delays calling write()
and the overhead of doing a bunch of Buffer copies is not worth the
slight benefit of calling write() fewer times.