[patches] Add a color management framework to weston

[Thomas Daede]

I am not sure that doing the color conversion in the compositor is the
correct place. Some of it has to be there to support vcgt, but for
more general conversions, it gets complicated quickly.

Color correction is most important for artists doing work in something
like the GIMP. Programs like this (as of GIMP 3.0, at least) generally
work in higher bit depths - 16 bit, half float, or sometimes 32 bit
float. It's much better to do conversion in the higher bit depth, then
dither to the final display depth. Doing this with the compositor
involves supporting all of these texture formats for subsurfaces -
also, the toolkit has to support subsurfaces, because generally the UI
will be some lower bit depth, or not need correction.

Converting bit depths in the compositor would also require an extra
buffer allocation and copy in the compositor.

RGB images are also not the only thing that needs to be color
corrected - for example, 10bit YUV video streams might want to be
color corrected too. If we were to go as far as converting bit depths
in the compositor, it wouldn't be much to add this.

I think that providing color space regions to the client, relative to
the client's buffer, including vcgt settings, would shove a lot of
complexity away to clients that are already used to dealing with it.

> The compositor should be able to draw N polygons for the N intersections of a surface with each output, each using a different shader?
> You absolutely do not want to put an if based on a pixel value into a glsl shader. It is really slow.

This is the correct way, I think. Splitting surfaces by monitor also
has other unrelated benefits, like being able to sync separately to
each monitor - it probably should go somewhere else.