Site aliases should not be cached in the options context

I whipped this together because it was easy, won't cause any compatibility problems with existing config files, and will reduce the size of the results record returned by backend_invoke by quite a bit.

As an added bonus, this patch also makes it possible to define a 'config-path' in your alias. If you do, the config file (drushrc.php file) referenced will be loaded when the alias is first fetched. This fell out naturally from the equivalent code that loads the drushrc.php file from the 'sites' dir of an alias when it is first loaded.

I realize there are some minor interaction issues with this patch that need to be worked out, particularly with respect to when the options of an alias are added to the 'alias' context.

Edit: You're right, the 'alias' context is only used as you describe above, or when you use an alias in certain commands, such as 'sql-sync alias1 alias2'.

Regarding using $aliases instead of $options['site-aliases'], the later is a little more convenient in the following snippet from drush_load_context:

      foreach (array('site-aliases', 'command-specific') as $option_name) {
        if ((isset($options)) && (array_key_exists($option_name, $options))) {
          $cache =& drush_get_context($option_name);
          $cache = array_merge($cache, $options[$option_name]);
          unset($options[$option_name]);
        }
      }

With only two such examples, we could easily enough unroll this loop to use $aliases and $command_specific. I could even add an array_merge($options['site_aliases'], $aliases) to keep backwards-compatibility with old configuration files, if anyone thought that was important.

Edit: I have another solution very similar to the suggestion above, except that it merges $aliases into $options and then runs the code above unchanged. Doing it this way is better vis-a-vis the reconciliation of site alias options and options in a configuration file. Patch available shortly.

Here is a substantially improved patch. It does the following things:

1. Alias definitions are loaded into a 'site-aliases' context, where they will not become part of the backend_invoke results.
2. In drush configuration files, $options['site-aliases']['mysite'] = ... still works, but $aliases['mysite'] = ... is now preferred.
3. Similarly, $options['command-specific']['dl'] = ... still works, but $command_specific['dl'] = ... is now preferred.
4. 'command-specific' and 'site-aliases' can be included inside a site alias, if desired.
5. A site alias may define a 'config' option, which will cause that config file to be loaded whenever that alias is used. The config file loads as if it were specified by --config; it does not go into the 'source' or 'target' contexts for sql-sync or rsync.
6. Site aliases that are defined in a site-specific configuration file, or inside of another site alias may now be used freely in any context that names the site or alias that defines them. For example, if you define a site alias called 'peer' in all of your site-specific configuration files, then drush sql-sync peer mysite and drush sql-sync mysite peer will both work.
7. rsync is now DRUSH_BOOTSTRAP_DRUSH, but it calls drush_bootstrap_max so that you can use it with aliases when there is no current bootstrapped site, but the current site is still assumed to be the base dir for relative paths when aliases are not used.

Kind of a lot for one patch, but all of this stuff was interrelated, and this cleans things up quite a bit. These changes shouldn't break anyone; if it does, it's probably a bug.

That depends on how quickly you want to get 3.0 out. This could be committed now (after review) if you were going to do beta-2 in about a week, and rc1 a week after that. If you wanted to do rc1 followed by a quick 3.0 stable, then I'd go ahead and do that, and put this in 3.1.

My preference would be to put this in 3.0-stable, since $aliases is nicer than $options['site-aliases'], and there are good performance benefits to this wrt backend_invoke. These changes are not deep (no substantial change to the way things work), but they are broad (touches a lot of different parts of the code), so although I tested it, I wouldn't want to put it in a 'stable' release without some time at HEAD. A couple weeks or so is probably enough time to ferret out any missed bugs.

Okay, thanks. I'll wait for Adrian to review; feel free to commit if you think it's ready, or bounce it back to me if you want changes.

This is the same as #6, except there is a trivial change: drush site-alias aliasname --full prints "$aliases['aliasname'] = ..." instead of "$options['site-aliases']['aliasname'] = ...".