Client types generalized.

Because of output buffer limits Redis internals had this idea of type of
clients: normal, pubsub, slave. It is possible to set different output
buffer limits for the three kinds of clients.

However all the macros and API were named after output buffer limit
classes, while the idea of a client type is a generic one that can be
reused.

This commit does two things:

1) Rename the API and defines with more general names.
2) Change the class of clients executing the MONITOR command from "slave"
   to "normal".

"2" is a good idea because you want to have very special settings for
slaves, that are not a good idea for MONITOR clients that are instead
normal clients even if they are conceptually slave-alike (since it is a
push protocol).

The backward-compatibility breakage resulting from "2" is considered to
be minimal to care, since MONITOR is a debugging command, and because
anyway this change is not going to break the format or the behavior, but
just when a connection is closed on big output buffer issues.
Assign an unique non-repeating ID to each new client.

This will be used by CLIENT KILL and is also a good way to ensure a
given client is still the same across CLIENT LIST calls.

The output of CLIENT LIST was modified to include the new ID, but this
change is considered to be backward compatible as the API does not imply
you can do positional parsing, since each filed as a different name.
New features for CLIENT KILL.
CLIENT KILL: fix closing link of the current client.
CLIENT KILL API modified.

Added a new SKIPME option that is true by default, that prevents the
client sending the command to be killed, unless SKIPME NO is sent.
Cluster: Include myself IP in nodes when available

Previously, the node you ran CLUSTER NODES on always reported itself
as IP:Port = ":0" in the node output.  The client requesting
the current node map would have to parse "myself" from the
flags and replcae the IP:Port with the IP:Port of the instance used
to retrieve CLUSTER NODES.  It seemed a bit convoluted.

If the user sets a bind address in redis.conf, we can use that for
the IP of this instance.  If the user doesn't set a bind address,
we fall back to the original ":0" behavior.
Cluster: add COMMANDS command

COMMANDS returns a nested multibulk reply for each
command in the command table.  The reply for each
command contains:
  - command name
  - arity
  - array of command flags
  - start key position
  - end key position
  - key offset step
  - optional: if the keys are not deterministic and
    Redis uses an internal key evaluation function,
    the 6th field appears and is defined as a status
    reply of: REQUIRES ARGUMENT PARSING

Cluster clients need to know where the keys are in each
command to implement proper routing to cluster nodes.

Redis commands can have multiple keys, keys at offset steps, or other
issues where you can't always assume the first element after
the command name is the cluster routing key.

Exposing command flags also helps client developers so they can
provide better behavior under different conditions
for readonly commands, write commands, admin commands, etc.

Using the information exposed by COMMANDS, client implementations
can have live, accurate key extraction details for all commands.

The only way Cluster clients can effectively route commands is
by knowing the details of keys for each individual Redis command,
so let's just expose that information directly when requested.

Tiny output sample:
127.0.0.1:6379> commands
  1) 1) "llen"
     2) (integer) 2
     3) 1) readonly
     4) (integer) 1
     5) (integer) 1
     6) (integer) 1
  2) 1) "setbit"
     2) (integer) 4
     3) 1) write
        2) denyoom
     4) (integer) 1
     5) (integer) 1
     6) (integer) 1
  3) 1) "info"
     2) (integer) -1
     3) 1) readonly
        2) loading
        3) stale
     4) (integer) 0
     5) (integer) 0
     6) (integer) 0
Cluster: PUBLISH when cluster state has changed

Clients should be able to listen to any instance and get
updates about the state of the cluster.

At a minimum, the clients should be immediately notified when
they need to refresh cluster state due to promotions/failovers.

This commit implements that minimum.

In the future it would be nice to PUBLISH more granular detail about:
  - ranges of slots changing ownership
  - new instances added/removed
  - instance state changes (fail?, fail, ...)

Those additions would be a subset of the blunt hammer approach
of "one notification for all state changes."  Clients will
probably have a common refreshClusterState() that is idempotent
for nodes with no changes, so updating the entire state shouldn't
be a huge burden (updating individual state like slot ownership
would be more efficient, but also requires adding more
special cases instead of just refreshing the world in the same
manner you use during basic initialization anyway).

For updates, you should SUBSCRIBE to _every_ node in your cluster.

You will receive multiple updates for every event, but clearly you
can't subscribe to just one instance.  If that one instance
goes down, you get no updates! Every event is tagged with the
current cluster epoch, so keep a record of the last cluster epoch
you acted on. When other nodes repeat the state change notification
for the same epoch you can just ignore them.
Cluster: Add CLUSTER SLOTS command

CLUSTER SLOTS returns a Redis-formatted mapping from
slot ranges to IP/Port pairs serving that slot range.

The outer return elements group return values by slot ranges.

The first two entires in each result are the min and max slots for the range.

The third entry in each result is guaranteed to be either
an IP/Port of the master for that slot range - OR - null
if that slot range, for some reason, has no master

The 4th and higher entries in each result are replica instances
for the slot range.

Output comparison:
127.0.0.1:7001> cluster nodes
f853501ec8ae1618df0e0f0e86fd7abcfca36207 127.0.0.1:7001 myself,master - 0 0 2 connected 4096-8191
5a2caa782042187277647661ffc5da739b3e0805 127.0.0.1:7005 slave f853501ec8ae1618df0e0f0e86fd7abcfca36207 0 1402622415859 6 connected
6c70b49813e2ffc9dd4b8ec1e108276566fcf59f 127.0.0.1:7007 slave 26f4729ca0a5a992822667fc16b5220b13368f32 0 1402622415357 8 connected
2bd5a0e3bb7afb2b56a2120d3fef2f2e4333de1d 127.0.0.1:7006 slave 32adf4b8474fdc938189dba00dc8ed60ce635b0f 0 1402622419373 7 connected
5a9450e8279df36ff8e6bb1c139ce4d5268d1390 127.0.0.1:7000 master - 0 1402622418872 1 connected 0-4095
32adf4b8474fdc938189dba00dc8ed60ce635b0f 127.0.0.1:7002 master - 0 1402622419874 3 connected 8192-12287
5db7d05c245267afdfe48c83e7de899348d2bdb6 127.0.0.1:7004 slave 5a9450e8279df36ff8e6bb1c139ce4d5268d1390 0 1402622417867 5 connected
26f4729ca0a5a992822667fc16b5220b13368f32 127.0.0.1:7003 master - 0 1402622420877 4 connected 12288-16383

127.0.0.1:7001> cluster slots
1) 1) (integer) 0
   2) (integer) 4095
   3) 1) "127.0.0.1"
      2) (integer) 7000
   4) 1) "127.0.0.1"
      2) (integer) 7004
2) 1) (integer) 12288
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 7003
   4) 1) "127.0.0.1"
      2) (integer) 7007
3) 1) (integer) 4096
   2) (integer) 8191
   3) 1) "127.0.0.1"
      2) (integer) 7001
   4) 1) "127.0.0.1"
      2) (integer) 7005
4) 1) (integer) 8192
   2) (integer) 12287
   3) 1) "127.0.0.1"
      2) (integer) 7002
   4) 1) "127.0.0.1"
      2) (integer) 7006