Drush context API. Get rid of globals and provide intra-process communication mechanism

As part of the refactoring I'm doing to drush to make the drush invoke api cleaner (http://drupal.org/node/349923), I am working on a patch that replaces the use of globals, and provides a central storage mechanism for Drush.

It also gives us the ability to do some introspection on how things were set, and where.

Normal usage is not changed, except for the fact that the -c / --config is now no longer a special case (ie: used INSTEAD of all the other configs, but in addition to).

It also allows us to fix things like this (from sql.drush.inc in drush_extras) :

    // Hack to make sure that drush_sql_dump sees the option.
    $GLOBALS['args']['options']['result-file'] = $file;
  }

This would be replaced with :

  drush_set_option('result-file', $file);

The context is returned as part of the json encoded output of the backend api (http://drupal.org/node/380688). This allows you to write a script which returns information about a site,
such as a command which returns how many nodes / users / terms a site has, and which modules it has enabled.

You can now write a command which iterates through all your sites and retrieves statistics of the entire set (ie: find sites with X version of module Y enabled, so you can determine which sites are affected by a security vulnerability.).

It allows a simple mechanism to save the options in a specific context back to the config file.
I do not know if this will be used by the core drush commands, but it's been pretty important to the provision system (ie: when we create a database for the site, we save it to the site drushrc.php, so we don't have to attempt to extract it from the site config, and we have a trusted source if the settings.php ever is broken.

A script that helps you to maintain patches might store a list of patches that have been previously applied to
the drupal platform, which could be useful when upgrading (as it could apply those patches in reverse, then upgrade, then attempt to re-apply the patches)

This patch seems a lot larger than it actually is, because of how well it's documented. It's about 200 lines of documentation for 100 lines of code.

As this is a non destructive patch that doesn't break any code I am aware of, I will commit it directly.
This ticket is mostly to document what change went in, and why.

Here's the main help :

/**
* @file
* The Drush context API implementation.
*
* This API acts as a storage mechanism for all options,
* arguments and configuration settings that are loaded into drush.
*
* This API also acts as an IPC mechanism between the different drush
* commands, and provides protection from accidentally overriding
* settings that are needed by other parts of the system.
*
* It also avoids the necessity to pass references through
* the command chain and allows the scripts to keep track
* of whether any settings have changed since the previous
* execution.
*
* This API defines several contexts that are used by default.
*
* Argument contexts :
* These contexts are used by Drush to store information on the command.
* They have their own access functions in the forms of @drush_set_arguments,
* @drush_get_arguments, @drush_set_command, @drush_get_command.
*
* command : The drush command being executed.
* arguments : Any additional arguments that were specified.
*
* Setting contexts :
* These contexts store options that have been passed to the drush.php
* script, either through the use of any of the config files, directly
* from the command line through --option='value' or through a JSON
* encoded string passed through the STDIN pipe.
*
* These contexts are accessible through the @drush_get_option and @drush_set_option
* functions.
*
* These contexts are evaluated in a certain order, and the highest priority value
* is returned by default from drush_get_option. This allows scripts to check whether
* an option was different before the current execution.
*
* Specified by the script itself :
* process : Generated in the current process. These are discarded at the end of the call.
* options : Passed as --option=value to the command line.
* stdin : Passed as a JSON encoded string through stdin.
*
* Specified by config files :
* custom : Loaded from the config file specified by --config or -c
* site : Loaded from the drushrc.php file in the Drupal sites directory.
* platform : Loaded from the drushrc.php file in the Drupal root directory.
* user : Loaded from the drushrc.php file in the user's home directory.
* drush : Loaded from the drushrc.php file in the same directory as drush.php.
*
* Drush commands may also choose to save settings to their matching configuration
* file through the drush_save_context() function.
*/