The window backend triggers a callback of the vout, and the vout
forwards this to the display using another callback. There are several
unfortunate layers of glue and indirections in the callchain. In
particular, we need to persist these ICC profile objects in some layer,
because of init order between windowing system and the window / vout
display module itself. I've chosen to add them to `vout_display_cfg_t`
because it fits well with the other "dynamic window state" properties in
there.

This approach also allows capable vouts to read directly from the
allocated ICC profile memory, minimizing the number of memcpys.