Start fleshing out error handling and more correct connection handling.

* for now, fiddle with debugging a bit
* and limit the number of connections to 1
* disable keepalive - to trigger the other end to close the connection on us
  after one request.
* add a per-request latency that we implement as a wait between queuing
  a new request and when we actually call into libevhtp to create / issue
  the HTTP request.
* add a way to attempt to cancel a queued HTTP request - used when we are
  shutting down the connection so we don't try to do the HTTP request.
* if a HTTP request is requested on a connection that's shutting down,
  error out.  Don't try to issue a request on a gone or about-to-be-gone
  evhtp_connection .

The fundamental problem here is that we don't (yet!) know when the request
has ended whether to treat the connection as persistent or not.
So if we issue another request it may fail because the connection is
being torn down.

What I don't want to do here is to have errors show up in the output
because we issued a request on a channel that wasn't persistent.
That'll skew the results.  Instead, I'd like to be able to tell if
the server isn't indicating it's a persistent connection and just
terminate it.

Then I can determine:

* whether or not the client sent a "I'd like to keep the connection
  open" message;
* whether or not the server is closing a connection we've asked to
  stay keepalive.

Then I can assign the close to be expected or unexpected.

So, that'll come next.  Right now I'm just trying to get my head wrapped
around the connection error conditions so things don't segfault.