This prevents the following sort of thing from being confusing:

```javascript
stream.on('data', function() { console.error('got data'); });
stream.pause(); // stop reading

// turns out no data is available
stream.push(null);

// Hand the stream to someone else, who does stuff...
setTimeout(function() {
  // too late! 'end' is already emitted!
  stream.on('end', function() { console.error('got end'); });
});
```

With this change, the `end` event is not emitted until you call `read()`
*past* the EOF null.  So, a paused stream will not swallow the `end`
event and emit it before you `resume()` the stream.

Closes #5860

In streams2, there is an "old mode" for compatibility.  Once switched
into this mode, there is no going back.

With this change, there is a "flowing mode" and a "paused mode".  If you
add a data listener, then this will start the flow of data.  However,
hitting the `pause()` method will switch *back* into a non-flowing mode,
where the `read()` method will pull data out.

Every time `read()` returns a data chunk, it also emits a `data` event.
In this way, a passive data listener can be added, and the stream passed
off to some other reader, for use with progress bars and the like.

There is no API change beyond this added flexibility.

If a transform stream has objectMode = true, it should
allow falsey values other than (null) like 0, false, ''.

null is reserved to indicate stream eof but other falsey
values should flow through properly.

The stall is exposed in the test, though the test itself asserts before
it stalls.

The test is constructed to replicate the stalling state of a complex
Passthrough usecase since I was not able to reliable trigger the stall.

Some of the preconditions for triggering the stall are:
  * rs.length >= rs.highWaterMark
  * !rs.needReadable
  * _transform() handler that can return empty transforms
  * multiple sync write() calls

Combined this can trigger a case where rs.reading is not cleared when
further progress requires this. The fix is to always clear rs.reading.

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

Just use stream.push(outputChunk) instead.

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.

The refactor in b43e544140ccf68580c02e71c56d19b82e1e1d32 to use
stream.push() in Transform inadvertently caused it to immediately
consume all the written data, regardless of whether or not the readable
side was being consumed.

Only pull data through the _transform() process when the readable side
is being consumed.

Fix #4667