Site-install in multi-site with Drush aliases and Drupal sites.php aliases

This pull request follows from [this issue](https://drupal.org/node/1824072) that was ongoing discussion on `drupal.org`.

I'll copy the description of the issue from the last comment I put there:

This change was never proposed to say that `--sites-subdir` was redundant (see previous comments on the issue linked above). It was proposed because, in `site-install`, `drush`'s ability to detect the right site folder was inconsistent across different ways of doing it under particular circumstances. I'll try and explain the scenario a bit better than I did in the past.

We have a number of sites in multisite configuration. Let's say that `ls sites` gives us this

```
all
example.com
example.net
default
```

The `default` folder is not used.

The circumstances I am talking about are to be found in `sites.php`: 

```php 
<?php

$sites['example.com'] = 'example.com'; // Live domain.
$sites['www.example.com'] = 'example.com'; // Live domain.
$sites['com.live.mycompany.it'] = 'example.com'; // Alternate live domain (for admin access, or similar).
$sites['com.stage.mycompany.it'] = 'example.com'; // Stage domain.
$sites['com.test.mycompany.it'] = 'example.com'; // Integration/QA domain.
$sites['com.local.mycompany.it'] = 'example.com'; // Local development domain.

$sites['example.net'] = 'example.net'; // Live domain.
$sites['www.example.net'] = 'example.net'; // Live domain.
$sites['net.live.mycompany.it'] = 'example.net'; // Alternate live domain (for admin access, or similar).
$sites['net.stage.mycompany.it'] = 'example.net'; // Stage domain.
$sites['net.test.mycompany.it'] = 'example.net'; // Integration/QA domain.
$sites['net.local.mycompany.it'] = 'example.net'; // Local development domain.
```

We also have aliases set up for all sites, e.g.

```php

$aliases["local.project.com"] = array (
  'root' => '/var/www/drupal-root',
  'uri' => 'com.local.mycompany.it',
  'path-aliases' => 
  array (
    '%site' => 'sites/example.com/',
  ),
  '#name' => 'local.project.com',
  '#file' => '/var/www/drupal-root/sites/all/drush/local.project.aliases.drushrc.php',
);

$aliases["local.project.net"] = array (
  'root' => '/var/www/drupal-root',
  'uri' => 'net.local.mycompany.it',
  'path-aliases' => 
  array (
    '%site' => 'sites/example.net/',
  ),
  '#name' => 'local.project.net',
  '#file' => '/var/www/drupal-root/sites/all/drush/local.project.aliases.drushrc.php',
);
```

Replace `local` with either `live`, `stage` or `test` and you'll have all the possible aliases that are compiled to target these sites.

So far I've set the scenario, and I hope, if I am not mistaken anything, that we all agree that in every circumstance, the site folder for the `example.com` site is always `example.com` regardless of whether the site is being accessed from one or the other of all the acceptable URLs mapped to that folder (e.g. www.example.com or com.local.mycompany.it). Same thing holds for `example.net` and all other potential sites (all set-up the same).

That said, here's a number of ways I could install one of these sites with drush: 

```bash
$ drush si my-profile -l example.com
$ drush si my-profile --sites-subdir=example.com
$ cd /path/to/sites/example.com && drush si my-profile
$ drush si my-profile --uri=http://com.local.mycompany.it
$ drush @local.project.com si my-profile 
```

With the patch applied, `$sites_subdir` will always be set to `example.com`.
With the non-patched code, `$sites_subdir` will be set to `example.com` (correct) with the first three commands, but will be set to `com.local.mycompany.it` (incorrect) with the last two commands.

Given that there is a `sites.php` telling Drupal that `com.local.mycompany.it` is mapped onto the `example.com` directory, I reckon the behaviour of the non-patched code is wrong, whereas the patch brings in the correct behaviour.

Unfortunately I am not too sure how to reflect this into a valid test, being quite unfamiliar with `drush` internals.
I'll try and have a go now, that I've got some spare time on my hands (part of which I've just burnt to write all this :D).

Cheers, 
 
 V

PS: this might still need a unit test done for it; any contribution would be appreciated.