Dropping TorCtl's _read_reply and unescape_dots in favor of stem's
ControlMessage object. This should be largely transparent to users, the only
visible impact being...

- The _read_reply method now only raises TorCtlClosed or TorCtlError
  exceptions, not socket.error (which was a pita to catch since it's not a
  subclass of TorCtlError). Exception messages differ.

- TorCtl would strip trailing whitespace from the content, stem preserves it.

- When TorCtl.Connection._loop encountered a CLOSE message it would set the
  socket (self._s) to None. I'm not sure why it was doing that, and troubling
  since it didn't make any effort to close the socket. I've removed it.

- The behavior of stem in the case of malformed tor responses differs...
  - Both stem and TorCtl read lines with \n terminators, though stem will raise
    a ProtocolError if it lacks a \r\n ending while TorCtl would accept it.

  - When reading a data block with an unescaped leading period TorCtl would
    strip it off (ie ". my line" would become " my line"). I'm not spotting how
    we're supposed to handle this in the control-spec so I'm leaving the period
    alone (I wonder if I should raise a ProtocolError instead...).

This also removes the BufSock class, which was largely unneeded. The socket
object has a makefile() method, which provides a file with a readline() method.
Using this not only simplifies the code but likely gives some performance
advantages.

The stem.types.ControlMessage class and parser have both unit and integration
tests - suggestions welcome if you spot something I missed. I've done manual
tests for the TorCtl integration and also exercised it by running arm.

Added support for detached heads

see:
http://www.sqlalchemy.org/docs/orm/session.html#lifespan-of-a-contextual-session
  "This has the effect such that each web request starts fresh with a brand new
  session, and is the most definitive approach to closing out a request."

try to use the same session for deletes and queries where possible,
this may be the cause of an ObjectNotFound exception that occurs
right after _update_db(), despite the Router object being in the
consensus and also in the db.

suspicious session behavior may require refreshing all
objects in order to keep tc_session and sessions bound
to Elixir synchronized