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.
Avoid stream gotchas in prior versions of Node/readable-stream

`readable-stream` v1.0.2 would not fire `'readable'` if the listener
was registered after writes, usually necessitating an explicit
invocation of the handler (in this case, `enqueue` in
`Mux#pipeFrom`). This was fixed upstream in Node.JS v0.10.something
and backported to `readable-stream` at some point before v1.1.9 (the
most recent at the time of commit).

Node.JS v0.9 does not need `readable-stream`, but doesn't appear to
have the backported fixes from v0.10. For the sake of completeness,
I've rejigged the mux roundrobin test to avoid that particular race.

`readable-stream` also monkey-patches `setImmediate` into the global
object if it's not present. However, I don't want to rely on that so
I've used my own, local solution.
Remove coincidence from sendContent test

I hadn't updated the test for `Connection#sendContent` to reflect the
different methods; but it was succeeding anyway, by coincidence.

So: make it break rather than succeed by checking the buffer argument
to sendContent, then make the test succeed by calling it
correctly.

Additionally, testing a list of fake messages doesn't really cover any
more bases than testing a single message.
Test in Node.JS v0.11 too
Uuuuuse striiiict
Running tests with several versions of Node.JS

All applicable versions of Node.JS, that is.
Mention extra Node.JS versions supported
Move confirm machinery to channel.js

This makes it a bit more delicate, since #pushConfirmCallback must be
called in very specific circumstances; but it makes the machinery
easier to test, e.g., in the case of out-of-order acknowledgements.
Advance the unconfirmed window over gaps

If acks arrive out of order, there may be gaps in the window. Whenever
we would advance the low water mark -- that is, when the tag is the
same as the low water mark -- we have to keep moving the window until
its either empty, or there's an unconfirmed message. To be able to
distinguish between entries that have already been resolved and
entries that are undefined (e.g., because a callback argument was not
supplied), `null` is used to mark resolved entries, and falsey
callbacks (which might otherwise be null) are replaced with `false`
specifically.
Use callbacks instead of promises for ConfirmChannel#publish

A disadvantage to returning promises from ConfirmChannel#publish (and
thereby ConfirmChannel#sendToQueue) is that it can no longer return a
boolean indicating write buffer overflow. So instead of returning a
promise, take a callback as the last argument. It's easy enough to
make it resolve a promise you've cons'ed beforehand.
Implement consumer cancel notification

This is a RabbitMQ extension: if a consumer will not receive any more
messages, RabbitMQ will send a cancel frame.

The most straight-forward, and I think idiomatic, way of representing
this is by calling the consumer callback with `null` instead of a
message. This lines up with how readable streams work (push `null` to
indicate no more values), and doesn't require any changes to the API
(other than the possibility of getting called with a null).
Account for consumer cancel in README example
Detect invalid frames and better handle handshake errors

Uncritically accepting the size given in frames may lead to
.. difficulties. So, look at the size first, then check for the frame
end marker. (Not done yet: check against the frame max)

Make sure errors from parsing frames make their way into either an
'error' event, or a handshake failure.
Clean up frame (error) handling

1. `Connection#step` now takes a (Node.JS-style) callback, rather than
having to mess with `.accept`.

2. `Connection#run` -> `Connection#acceptLoop`, a more fitting name I
think. It's still indirected through `.accept`, so that it can be
swapped out when e.g., closing the connection.

3. While running `acceptLoop`, invalid frames are signalled by a
`'frameError'` event, rather than calling some method. I may as well
use the mechanisms available.
Rename mocknet to util

It's no longer just pretend socket helpers.
Detect frame decoding problems and raise them