Make sure context emits 'close' when the connection closes

Also: we need to decrement the latch at least once for it to fire.
Mention close, error events, and expiration in README
Release notes and version bump for v0.2.2
Explain the two branches in the README
Convert expirations to strings, to avoid surprises

.. and to conform to the README. Issue 45.
Expirations must be stringified, until the next release.
Add syntax highlighting to Readme
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.
Test for end(chunk, encoding)
Make sure all reps are connected before sending anything

I have to make sure each rep socket gets a single message, so that
each can send a message back (out of order). Without doing the
`connect`s serially, there's a race between all the reps being
connected and the req sending.