Add SCRIPT NAME and EVALNAME
Add pubsub scripting support

This commit allows you to subscribe lua scripts to pubsub channels.

For regular subscribes, your lua script receives the channel as
ARGV[1] and the message published as ARGV[2].

For pattern subscribes, your lua script receives the exact channel
as ARGV[1], the message published as ARGV[2], and the pattern the
script subscribed to as ARGV[3].

For ease of maintenance, you may subscribe a *named* script to a
pubsub channel, from creating a Name->SHA binding with
SCRIPT NAME [name] [SHA], or you may use a SHA directly.
The benefit of using a named script is you
can point the name to updated scripts later without having
to unsubscribe and resubscribe all your scripts to your channels
again.

This commit adds commands:
  - SSUBSCRIBE
  - SUNSUBSCRIBE
  - SPSUBSCRIBE
  - SPUNSUBSCRIBE

Each command works like:
    SSUBSCRIBE [channel] [script1] [script2] ... [scriptN]

Note: unlike other pubsub commands, the additional arguments are
*scripts* to subscribe instead of a list of channels themselves.
You can only subscribe/unsubscribe one channel per
{S,SUN,SP,SPUN}SUBSCRIBE command, but you may
subscribe multiple scripts at once.

Pubsub channels protect themselves from having the same named
script added multiple times on the same channel.
Though, if you give one script sha two different names,
then that gets around the channel knowing you're subscribing
twice.  The result of subscribing the same script to a channel
more than once means your script will get run multiple
times for each published message.

The safest way to subscribe a script to a channel:
    SCRIPT LOAD [script] => returns SHA
    SCRIPT NAME [scriptName] [SHA]
    SSUBSCRIBE [channel] [scriptName]

From there, if you want to update your script, you just run
another SCRIPT LOAD, get the resulting SHA, then run
SCRIPT NAME using your old name with the new SHA to re-point
the name to your new script.

The command names aren't pretty, but they match other command
naming conventions.

If you do a SCRIPT FLUSH while you have scripts subscribed to
pubsub channels, the script names remain subscribed to your channels,
but their backing code goes away, so they stop running.  If you
re-SCRIPT LOAD then re-SCRIPT NAME the script as you had before
the SCRIPT FLUSH, the pubsub scripts will continue excuting without
you needing to unsubscribe and resubscribe them.  Note: PUBLISH
will still report the scripts are "receiving" the published
message after a SCRIPT FLUSH, but nothing will be happening.  It's
the same as having a dead client connected until you re-attach
the script to the subscribed name on the channel.
Convert in-place pubsub scripts to async execution

This commit allows lua scripts subscribed to a pubsub
channel to PUBLISH to other channels that also have
listening lua scripts.

Yes, if you do The Bad Thing and subscribe a channel to
itself you'll infinite loop Redis.  Do not infinite loop Redis.
(Note: this also allows an indirect way for lua scripts to
call other lua scripts)

How it works: Each PUBLISH to a channel with a listening
lua script gets appended to a list of events to process
during the next server cron (default: 10 Hz).

Before this commit, lua scripts were executed before the PUBLISH
command returned to the caller.  Now lua scripts get executed on
average 50ms after your PUBLISH command.
Add client to pubsubPublishMessage where possible

This strange change exists so Redis tcl tests work.

The Redis tcl test suite runs clients on DB 9.  We have
to inform the pubsub scripts about which DB the client was using
when PUBLISH was called.  The script client gets updated with
the DB of the PUBLISH caller (or back to DB 0 if no publish
client existed) so when the script runs later, it runs
under the context of the correct DB.

The only way to update the pubsub
script with each PUBLISH call is to put the caller/publisher
into the PublishMessage command.

Lua scripts can also SELECT their DB internally, but that
requires, at least for testing, leaking implementation
details of the test into the script.  The DB selected in an
async script is not persisted on the next call.  Every call
has the DB reset to the DB of the caller (or DB 0 if the
caller is internal to Redis (NULL)).

It's not pretty, but it works.
Add tests for pubsub scripting
Correct coding conventions

Translate all my lowerCamelCase variables to under_case
Remove forceCommandPropagation from SCRIPT NAME

Names are local per-node (all operations are replicated
by sha of the script), so we don't need to
forceCommandPropagation when we set a name.
Fix redis argument table script sub arity