Extendable API to manage Drush aliases.

Now that Drush aliases are getting close to completion #733256: Aliases should be loaded from a central location rather than drushrc.php, I want to use aegir to generate and manage these aliases.

I've already been working on some proof of concept code here - #723288: Introduce the concept of 'shortnames' for all major entities., and that issue is also a dependency for this.

What needs to happen is that when you edit or modify an item in the front end, this will actually translate into a drush command that re-generates the alias configuration file for the entity you have modified.

So, when you create a new platform, the front end will then register the platform configuration with the backend and the following verify task will operate on the alias you have generated.

This ties into #736726: Refactor provision to match the new Services API..
Once we have re-factored the backend into classes, that get instantiated based on a set of options passed on the command line, we will be able to generate an alias which captures the exact set of arguments needed to spawn the necessary objects.

So in the future, instead of the front end needing to iterate through the entire tree of related data to generate the exact set of command line options on every call it does to the backend, it will simply be able to use the generated and managed alias as an argument.

This is related to #586000: make a "server verify" task
By passing a server , platform or site alias as the context for the provision-verify command (ie: drush @context provision-verify), we will be able to very cleanly verify each of the different components separately. This will also allow a very clean mechanism for
storing the multiple database server credentials we require.