Formatting
More formatting
Fix variant reply handling
Initial commit of formalized "redirection" timeout logic

When phpredis is communicating with a cluster, there are two
different kinds of timeout events.

The first, is your standard read or write timeout where the socket is
blocked either because of network issues, or because Redis is taking
longer than the timeout to complete the request.

The second is unique to cluster.  Because Redis Cluster attempts to
automatically failover (in the case of replicas), phpredis cluster
will attempt to get data from a node where it thinks the key would
live, and upon a failure to connect, try a different node (at random).

This is because Redis could be resharding the connection and may point
the client to a new (now good node).  However, if it's not yet detected
a failure, it will just bounce us back to the prior node (which could
be actually down or have just sputtered due to various issues).

So in this case, phpredis uses a second timeout mechanism where we keep
track (in milleseconds) when we entered the query/response loop.  Once
we've been unsuccessful up to this timeout, phpredis will abort with
a different (catchable) exception.

TODO:  It may be a good idea to implement some small delay, so we don't
hit the cluster with lots of requests over and over until the cluster
comes back.