Color management architecture: color transformations and a plugin

This patch series sets up the stage for implementing color management features in the future. See also #467 (comment 814985) for a bullet point plan and #467 (comment 864054) for some diagrams.

The main concept introduced is a color management component, struct weston_color_manager. Two such are added:

• no-op is a built-in, no-dependencies, always available color manager whose job is to do nothing. Using this one, Weston will behave exactly as it has before. This is needed to make color management a first class citizen in libweston core, rather than a hassle bolted on externally.
• color-lcms is a dynamically loadable plugin that depends on Little CMS. Right now it is functionally equivalent to no-op.

In time, color-lcms is supposed to grow to the full color management plugin: processing ICC files as output profiles, receiving content color profiles from clients, and producing the required color transformations to show client content correctly on each output. It will also be crucial for HDR support as it will produce all the needed tone mappings.

While color-lcms is the "brains" that decides what color transformations should be done, GL-renderer is the one that will implement those color transformations as metadata driven operations in GL shaders. These operations could be things like applying a one- or three-dimensional look-up tables or some parametric color transforming functions. This MR does not define any operations, those will be introduced later as members of struct weston_color_transform.

As computing the necessary color transformation may be expensive, the framework introduced here promotes extensive caching.

The color transformation may be different (or same!) for each surface-output pair. The framework itself caches a reference to a struct weston_color_transform for each such pair. A struct weston_color_transform will be sub-classed and created by the color manager, and the color manager is intended to use existing objects extensively, hence they are reference-counted. These objects will be created by calls to the color manager on-demand as outputs are repainted.

GL-renderer may also need to do expensive preparations for implementing a weston_color_transform, e.g. creating textures. These can be cached with the weston_color_transform by hooking up GL-renderer private data in the destroy signal listener list. DRM-backend can do the same once it starts implementing transformations with KMS properties. As the color manager makes sure to use existing objects, so does the GL-renderer benefit from the already created GL state.

Once created, the weston_color_transform objects are immutable, so there is no need for checking whether cached references or data is up-to-date. Cache invalidation is intended to work by destroying all related weston_color_transform objects when an output or a surface changes its color profile. This is not hooked up, as there are no mechanisms to set or change color profiles yet.

This proposal uses the convention that a NULL struct weston_color_transform * means identity mapping. While it is very convenient, it does make some error conditions awkward to detect, hence some checks are overlooked. However, otherwise the color manager would need to create a weston_color_transform object that can trivially be identified as the identity mapping, since several places will demand, assert, or short-circuit the identity mapping.

This MR is intended to land after !575 (merged) even though they have no fundamental dependency.

The concepts of color profiles or color spaces and the CM&HDR protocol (wayland-protocols!14) support are left as future work. I imagine that the color manager will inspect weston_surface and weston_output members to find their color profiles. The color manager API will need new functions for creating color space objects, cached equally aggressively as the color transformation objects.

I have looked at @swick's work in https://gitlab.freedesktop.org/swick/weston/tree/color-management-rebase a lot for the inspiration here.

Cc @vitalyp