WIP: Porting USC to use MirAL instead of mirserver

Created by: WebDrake

Following discussion on the message boards (https://forums.ubports.com/topic/990/organizing-unity8-work), this PR covers the complete state of my work so far on porting USC from the mirserver API to MirAL. It's the same patches as in https://github.com/WebDrake/unity-system-compositor-yunit/pull/1 but rebased on the bionic branch.

This PR is not intended to be merged itself (too many patches, too many moving parts!) but can serve as a starting point for discussion on how this transition should be managed in UBPorts. Ideally, I'd like to make these changes via multiple incremental PRs, all going through CI and whatever other testing is available.

It also means that if I vanish for any reason, the work is still here for other people's reference.

A few notes:

• the main goal of this work was to incrementally remove direct uses of the mirserver API and replace by appropriate MirAL equivalents, while (ideally) not changing behaviour in any way

• the current state of things sees a rather spaghettified main function. This is a deliberate choice, to pick things apart in an incremental fashion before putting things back together in a way that suits things best for MirAL. However, different approaches are probably possible: for example, instead of removing the old USC::Server class entirely, it might better be repurposed as an "own all the app resources" class with no dependency on mir::Server.

• the current state of things is that all the "easy" refactoring has been done and now we have to start looking at the components of USC with more subtle dependencies on mir::server and mir::input. A summary is here: https://github.com/WebDrake/unity-system-compositor-yunit/pull/1#issuecomment-347339346

• the code as written was tested on a xenial system with the Yunit PPA, and no problems were observed, but it was never tested in phone/tablet situations, since I really didn't have the facilities to do such tests.

What I'd suggest is that UBPorts should take a first look at this coming from the point of view of (1) whether this work looks sane AT ALL and (2) if so, what the requirements and possibilities are from your side in terms of testing, code quality, and managing the transition.

I've tried to document each patch with as much detail as possible about the logic of the changes, so hope that helps.

Anyway, {enj,destr}oy.