[meta] Re-think our object models & design patterns

See also #955018: ability to save new arbitrary data to a context from outside the service. I also remember talking with someone in London about having "subservices" to resolve that issue, but I can't find the issue right now.

basically, that discussion revolves around how it's impossible or very diffcult (i couldn't figure out how) to operate on multiple servers (which is usually done through the services modules) from outside services. to implement the subdir support, I had to hack into the Apache service directly, as opposed to be able to hook into it from outside.

it may not be a limitation of the code as much as problems with the documentation, but I couldn't figure it out in an afternoon.

Also, I had a lenghty conversation with @tizzo about Drush Fetcher. Basically, tizzo asked me if we were duplicating our efforts with Provision, and I answered that he was just laying the foundation for Aegir 4. ;) Fetcher is basically a clean room reimplementation of provision with closures, namespaces, autoloading and all sorts of interesting modularity. They have a similar object model than us, except it's much cleaner and understandable, as it is based on on Pimple as opposed to be a native, buggy and incomplete implementation like we do.

I think this would be a great basis for the rewrite of the backend I have been looking forward for years. A couple of things are missing from Fetcher, I believe:

* multi-server / cluster support - it operates only on a local environment, and is strongly oriented in the "creating a local dev env" approach
* the commandline interface is similarly limited to operate on an existing list of sites more than being completely autonomous
* migration from our current storage mechanism
* task / queuing system - there are some ideas about "jobs" and tasks right now, but those are fairly limited (see also #2049543: Refactor our queue using the Drupal Queue API)
* no nginx support
* no backward compatibility with all our contrib module fauna - although we could have backward compatibility shims
* lacks our "server" abstraction
* no DNS support
* limited or no multi-site support

Also, fetch basically re-implements drush make (in a way), so this conflicts with our current approach of reusing existing tools. We could, however, implement a fetcher subclass that would simply talk with drush make...

We also discussed how drush limited us severely - the code is getting old, and drush is used. I even proposed we start considering rewriting the drush core to be a simpler and better defined API (#smallcore anyone?), which was an interesting discussion, but quite an undertaking.

I do feel that a lot of those concepts belong to drush, and that was the basic idea behind our d() and class structure - that they would eventually get merged back into drush.

Anyways, we need to continue the conversation with @tizzo and the proviso people about this, for sure.

Again, I think we should seriously reconsider rewriting our backend with this, if we are to continue with PHP at all here. :)

@ergonlogic's https://www.drupal.org/project/aegir_objects is a step in the right direction for this issue.

Setting the status to postponed as it's not actionable right now.