More formatting
Created cluster specific option handling

Added distribution option to RedisCluster in preperation for
implementation of commands which can be distributed by the client.

The two distribution modes will be:

* DIST_OOE   : Maintain order of execution
* DIST_SPEED : Most efficient delivery

Either way, the RedisCluster object will need to return values that
were gathered in the same way they were sent in, but might execute
them in a different order if the option is set to DIST_SPEED.
Reformatting, spaces > tabs
Moved our typedef below all defines
Formatting updates
BUGFIX:  Hash the key, not the last member!
Transaction support

This is the initial commit supporting transactions in RedisCluster
via MULTI..EXEC.  Given that the data can be distributed across
many nodes, we accomplish transactions as follows.

1.  When entering MULTI mode, the cluster context state is changed
    to MULTI
2.  When we send a command to a node, we check that node's RedisSock
    state, and if it's still ATOMIC, deliver the MULTI command,
    updating the node's state to MULTI.
3.  When reading replies, we check if the RedisSock* is in a MULTI
    state, which means we need to issue the EXEC command.  We do
    this and then flip the state back to ATOMIC.
4.  On completion, everything is reverted to ATOMIC state and our
    reply callbacks are freed and set to NULL.

For transactions, we enforce writes such that they MUST be able to
be processed by the node in question (e.g. they can't work during
a reshard, because there is no way to know what has failed, etc).

This is the same as RedisCluster which will also cancel transactions
in the case where a request was made for data that is somewhere else.
Fixed HMGET, more MULTI support

Fixed HMGET so we don't leak memory when getting members
that don't exist.

Added a call to CLUSTER_RESET_MULTI() at the end of our
EXEC function, so afterwards we're not in MULTI mode.