Handle non-deserializable connect response

This problem has been seen sporadically in production but the
exact cause is not clear. Occasionally the client receives
a connect response that it cannot deserialize. This results
in an error and leaves the client in a zombie state where it
no longer attempted to reconnect.

With this change we catch errors and raise a ConnectionDropped
error. This is caught by the outer connection loop and the client
continues attempting to reconnect.
Merge pull request #95 from labisso/connect_deserialize

Handle non-deserializable connect response
make Close and Ping print the same as the rest

This makes the log message look like

Sending request: Ping()

instead of

Sending request: <class 'kazoo.protocol.serialization.Ping'>

Constructing a Ping object for each ping generates a lot of unnecessary
temporary objects, though, so this also creates a singleton object to
use for it.

It makes the equivalent change to Close for consistency's sake.
fix connection dropped message
Allow the caller to override the logger used.

We already have a logger associated with the client, and this makes it
easier to track which client is doing what when the logs are aggregated
on a log server.
Reduce log verbosity by making individual lines more useful

This makes it easier to match requests and responses when the logs are
aggregated on a log server.
Split debug logging into multiple loglevels

The getEffectiveLevel check is not actually necessary, the logger
already performs an isEnabledFor check when you use the
loglevel-specific methods (see Logger in python's logging module).

This also breaks DEBUG into two levels, INFO (for the request-response
cycle) and DEBUG (for the protocol-specific messages and pings).