Use a muxing readable stream to round-robin frames

By buffering channel frames (see
ea277447cd3b00690ebc1aec0a8478f027a1111c), I introduced a problem: I
have to pipe all the channel write buffers into the underlying
(socket) stream. This is conceptually fine; however `#pipe` isn't
really meant for this purpose, as witnessed by two unfortunate
effects.

Firstly, pipe hooks up a lot of event listeners on the destination
stream (the socket in my case), and many channels means many
listeners, causing EventEmitter to spit.

Secondly, the flow characteristics of the channels seem to be rather
unpredictable. My superficial expectation is that it would be 'first
come, first served'; that is, the first channel to show up would by
and large get the bandwidth (since it would tend to exhaust buffers,
and be the first 'drain' listener). NB *superficial*.

One solution to these problems is to create an intermediary that
reverses the listener relationship (avoiding the first Unfortunate
Effect) and round-robins reads among its incoming streams (mitigating
the second Unfortunate Effect). The algorithm I've used (in `mux.js`)
prioritises new streams, and thus intermittently publishing channels,
to avoid a variety of head-of-line blocking whereby regular publishers
of large frames hog the bandwidth. Well, in theory.

The inspiration comes from here, but don't blame the author for my
shallow interpretation:
https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
Mux directly to the supplied writable stream

Instead of presenting the muxer as a readable stream with packets from
each readable piped into it, just write directly to a stream
supplied. This avoids an intermediate buffer, as well a level of event
propagation.
Try to be close to #pipe given a single input

If there's just one input stream, there's no point in continually
dequeueing and enqueueing it while 'roundrobining'.
Simplest tests for mux
enqueue only needs to be called on 'readable'

Calling it explicitly at the end of `pipeFrom` meant it was called
twice, as the roundrobin test made clear. `'readable'` is emitted
straight away if there is data already, otherwise as soon as there is
data.