sway/server: stop advertising "srgb" color transfer function

[poisotf]

In anticipation of https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/442

A brutish approach, clients that require or assume wp_color_manager_v1::transfer_function::srgb to always be available will die.

On recent mesa and wine, this gives the desired outcome of vulkan VK_COLOR_SPACE_SRGB_NONLINEAR_KHR using no color management messages. Closes: #8918

If this causes issues, a safer alternative would be a change in wlroots to quietly reinterpret "srgb" as an alias for "gamma22"

[llyyr]

We should advertise both, there are high end displays out there which use the piecewise function and ITU-R BT.2380 has explicitly defined the piecewise function as the sRGB eotf.

We need to make this configurable instead and propagate the mess one level up to the end user, the MR you linked also doesn't remove the piecewise function anymore, just renames it instead.

[emersion]

There are two issues with the color-management protocol srgb TF:

• It's ill-defined: some clients use it to mean "whatever sRGB content expects", which is a gamma 2.2 TF. See: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/442
• Historically monitors have been using gamma 2.2, but some monitors are using piece-wise sRGB now. We already have a output <name> color_profile srgb|icc command, it would seem natural to add a new gamma22 entry (used by default), and reuse or rename srgb for piece-wise sRGB monitors. (It would also be nice to add edid as an additional profile, to use primaries from the EDID.)

[poisotf]

(I realize I've named this MR terribly : it changes the options passed by sway to wlroots, not sway's user-facing options)