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.
Sentinel: send SLAVEOF with MULTI, CLIENT KILL, CONFIG REWRITE.

This implements the new Sentinel-Client protocol for the Sentinel part:
now instances are reconfigured using a transaction that ensures that the
config is rewritten in the target instance, and that clients lose the
connection with the instance, in order to be forced to: ask Sentinel,
reconnect to the instance, and verify the instance role with the new
ROLE command.
Add SIGINT handler to cli --intrinsic-latency

If we run a long latency session and want to Ctrl-C out of it,
it's nice to still get the summary output at the end.
Merge pull request #1658 from mattsta/redis-cli-latency-clean-interrupt

Add SIGINT handler to cli --intrinsic-latency
add missing signal.h include
Merge pull request #1822 from vito/patch-1

add missing signal.h include
Add correct exit value to failed tests
Merge pull request #1824 from mattsta/fix-test-error-signal

Add correct exit value to failed tests
Test: tcl client, unset deferred var on close.
Test: Tcl client initial support for automatic reconnection.
Sentienl/Redis test: enable link reconnection in instances.tcl.
Test: use higher level redis.tcl proc to read replies.
Sentinel: handle SRI_PROMOTED flag correctly.

Lack of check of the SRI_PROMOTED flag caused Sentienl to act with the
promoted slave turned into a master during failover like if it was a
normal instance.

Normally this problem was not apparent because during real failovers the
old master is down so the bugged code path was not entered, however with
manual failovers via the SENTINEL FAILOVER command, the problem was
easily triggered.

This commit prevents promoted slaves from getting reconfigured, moreover
we now explicitly check that during a failover the slave turning into a
master is the one we selected for promotion and not a different one.
Sentinel test: add manual failover test.
Sentinel: send hello messages ASAP after config change.

Eventual configuration convergence is guaranteed by our periodic hello
messages to all the instances, however when there are important notices
to share, better make a phone call. With this commit we force an hello
message to other Sentinal and Redis instances within the next 100
milliseconds of a config update, which is practically better than
waiting a few seconds.
Sentinel test: unit 02, avoid some time related false positives.