staging/content-type: alternative content type hint support

I don't think content type should be tied to HDMI, or really any display behavior at all, so I adjusted !117 (closed) to be more general and not rely on HDMI or DRM definitions of content types. I still described a bit how a compositor would best present them in order to stay sort of compatible with it, but tbh that could be removed as well - content types "photo", "video" and "game" should be pretty self-explanatory both for what they mean and for what compositors would do with them (at least in regard to image processing).

Some use cases not tied to the HDMI spec or image processing that I have in mind would be changing the active mode, enabling / disabling vrr, changing vrr behavior (in regards to cursor updates), changing the latency policy, putting an fps counter on top of games, changing the display brightness, choosing what surfaces are best to put on overlay planes, that sort of stuff.

Closes #15 (closed)

TODO:

• If I understood the description correctly, CTA-861-G says that the "graphics" type is for content that may degrade when pixels aren't mapped 1:1. As I think that describes most content (which is not a photo, video or game) and is super vague, so I removed it. Any objections to that?
• any additional content types that should be there from the beginning on?
• 3 implementations:
  • KWin: https://invent.kde.org/plasma/kwin/-/merge_requests/2467
  • wlroots implementation: wlroots/wlroots!3599 (merged)
  • client implementation: https://github.com/mpv-player/mpv/pull/10262
• Review: @emersion
• 3 ACKs from members
  • @emersion for wlroots
  • @zzag for Kwin
  • @jadahl for Mutter