Rewrite to use amqplib

Implementing on amqplib makes it a lot simpler. The examples run, and
the tests pass (except for one that uses message expiry).

Also uses new-style streams, which means a lot less faff. I still
can't give a good account of flow control, though.
Use the channel directly in methods

This simplifies the code as well as avoiding needless synchronisation
once the channel is ready. Because the methods really *do* have to
synchronise, I patch them initially with versions that do so, then
unpatch themselves.

Any setup that must be done before other operations (e.g.,
constructing a queue for replies) is done in the constructor, with the
final promise used as the 'ready' signal for unpatching.
Factor out source/destination argument handling
Use confirms for flow control

The new-style streams API asks writable streams to invoke a callback
for each write, so that it can keep track of which are complete and
thereby limit its buffer. The channel API I'm writing to is similar to
the external API of streams (returns false if the buffer is 'full'). I
can either

 - just invoke the callback regardless of the write result; or,
 - start maintaining my own buffer; or,
 - use confirmations to signal successful writes

Of these, the first quickly leads to filling socket buffers, since the
stream implementation will happily keep writing (as I'm telling it
each write succeeds immediately). This tends to starve other I/O.

The second is just a pain, which seems contrary to the spirit of
newstreams; perhaps I've missed a vital, helpful bit of the API.

The last is rather heavy weight, since it means we wait for not only a
RTT but a RTT to a queue (thought this is mitigated a bit by RabbitMQ
coalescing acks). However it does also have the benefit of making all
writes that bit more certain, which serves the interest of
simplification.
Supply failure continuations in _write
Example of using rabbit.js just to send and receive messages

Non-interactive, and no integration with anything else.
Package file for easyamqp example
easyamqp example: report stats when interrupted
Wait on confirms for all published messages in PubSocket._write

Previously the pub socket, which sends to all its connections, was
supplying the _write callback inside the forEach; meaning that
 1. it would call it multiple times if there were many connects
 2. it would call it no times if there were no connects

This involves an extra dependency on when.js for its 'all' procedure.
readable-stream is a dependency if one is using Node.JS v0.8
Declare pub/sub exchanges as ephemeral for backwards compatibility
Release note and version bump for v0.2.1-amqplib
Write synchronously instead of using confirms

Previously I was using confirms to signal successful `_write`s. This
wasn't too bad for performance, since often confirms will acknowledge
many messages at once. However, it did pose a problem for setsockopt,
which is supposed to behave as though writes are synchronous: so, for
example, setting an expiry for one write then unsetting it applies the
expiry only to that write.

THe difficulty with just overriding `write` in the first place was
that amqplib had no (streams2) flow control. Newer amqplib has
per-channel flow control.
Tweak the easyamqp example
Merge branch 'master' into amqplib

Conflicts:
	RELEASE_NOTES
	lib/sockets.js
	package.json
	test/tests.js
Tighten up bolts

Remove spurious requires and vars.
Allow >1 in-flight requests on REQ

Done by giving each request a correlation ID and (assuming correlation
IDs are preserved by the repliers) making replies readable in the
order of the correlation IDs.
Let REQs have >1 request in progress

They still have to reply (write) in the order that the requests came
in, so if answering requires any asynchrony, the application will
either have to do more work to reorder answers, or only read one at a
time as before.

I've removed the prefetch for the REQ and REP. In the case of REP,
it's no longer necessary to be entirely synchronous. For REQ, it
wasn't enforcing anything much anyway -- only that the reply would be
buffered before another could be sent.
Socket#end now behaves like Writable#end. Socket#close just closes.
If a cancel is sent by the server (indicating that the underlying
queue has gone west), indicate so by causing the stream to emit 'end'.
Being the README up to date with developments

Developments in the world, and in this library.