Merge lp://qastaging/~vanvugt/mir/unwanted-alpha into lp://qastaging/mir

Extend mir_connection_get_egl_pixel_format to take additional hints
from the client's requested attribute list. This way the existence
of an alpha channel (chosen by the driver but unwanted by the client)
doesn't force Mir into a slower compositing mode (LP: #1480755).

I could have just hacked examples/eglapp.c and declared the bug fixed, but that would not suffice for other toolkits (particularly games). So this more long-winded solution solves the problem for everyone.

I also investigated the possibility that our dumb demo code was simply not finding the best EGLConfig by virtue of always truncating the list of configs to length one. But even if you look at the full list, the problem is present for every available EGLConfig (EGL_ALPHA_SIZE==8 even when I didn't ask for it).

Annoyingly the first version of mir_connection_get_egl_pixel_format
is actually returning the right result (the pixel format the driver
is using) so there's nothing immediately obvious to fix. But the right
pixel format is not necessarily the fastest one. If we can see the
client hasn't asked for an alpha channel then we should disable the
alpha channel. This way composite bypass can still be used on platforms
that always return an alpha channel (e.g. Mesa on Haswell always returns EGL_ALPHA_SIZE==8).

I'm fairly sure we only want to fix this on Mesa where the bug was
found. On Android we have a greater chance of supporting translucent
overlays in future so don't want to (and don't need to) use as big a
hammer (see TODOs in hwc_layerlist.cpp).