stream: Handle late 'readable' event listeners

In cases where a stream may have data added to the read queue before the
user adds a 'readable' event, there is never any indication that it's
time to start reading.

True, there's already data there, which the user would get if they
checked However, as we use 'readable' event listening as the signal to
start the flow of data with a read(0) call internally, we ought to
trigger the same effect (ie, emitting a 'readable' event) even if the
'readable' listener is added after the first emission.

To avoid confusing weirdness, only the *first* 'readable' event listener
is granted this privileged status.  After we've started the flow (or,
alerted the consumer that the flow has started) we don't need to start
it again.  At that point, it's the consumer's responsibility to consume
the stream.

Closes #5141