Program KMS "Colorspace" property from config file

This MR adds the libweston API for "colorimetry mode", which means the KMS "Colorspace" connector property. DRM-backend will program the property, and the value comes from weston.ini.

This is similar to the EOTF mode. Both settings affect the metadata sent to a display/sink, and that should make the sink interpret the pixel values accordingly. These modes are intentionally configurable: the administrator chooses what mode to drive a monitor in, and then it is the administrator's responsibility to also set a corresponding image description (e.g. an ICC profile) for the output and enable color management.

I tested this without setting a corresponding image description. That is, pixels were prepared with sRGB encoding, and I intentionally let the sink interpret the pixels as if they were encoded with BT.2020 colorimetry. This way I should be able to observe the differences between the colorimetry modes. On my AMD card, BT.2020 colorimetry messes up almost all colors. Black becomes green, light grey becomes pink. This proves that the KMS programming works, and probably the kernel driver does not quite handle it right as these results cannot be explained by simply misdecoding colorimetry. On my Intel Haswell iGPU, the colorimetry mode had no effect whatsoever, even though the "Colorspace" property exists. It could be my monitor that ignores the colorimetry mode and switches to BT.2020 decoding if and only if it is in HDR mode. Or maybe my monitor does not handle the colorimetry mode at all.

Theoretically, and by HDMI/DisplayPort/CTA specs, setting the colorimetry mode is a requirement for Wide Color Gamut as a part of most HDR standards.

This MR does not include integration with libdisplay-info in order to parse the supported modes from EDID. Here we just assume that everything that KMS allows to choose is also supported, which is of course false. EDID reading will come later.

cc @leandrohrb