backend: implement content-type based cursor throttling

[anriha]

This PR implements the wp_content_type_v1 protocol and refines the logic for cursor throttling on fullscreen windows with VRR enabled.

Currently, the compositor throttles cursor updates to ~24Hz for any fullscreen window to prevent VRR brightness flicker. While this is necessary for games and video playback, it creates a terrible user experience for native productivity applications (e.g., terminal emulators). On a 144Hz screen, a fullscreen terminal feeling locked to 24fps is jarring and unresponsive.

Changes

1. Protocol Support: Implemented wp_content_type_v1 to allow clients to specify their content
2. Smart Throttling Logic: The render loop now uses the content type to decide whether to skip cursor-only updates:
   • Native Apps (Type: None): Unthrottled. This restores smooth 144Hz mouse movement for terminals, browsers, and editors.
   • Video / Photo: Throttled. Preserves correct frame pacing and power saving.
   • Game: Throttled. Ensures the refresh rate matches the game's rendering rate to prevent VRR gamma flicker/judder. If we decide to implement tearing support that should probably override this.
   • XWayland: Throttled. Since XWayland windows do not currently support the content-type protocol, we assume fullscreen X11 windows are likely games and default to the "safe" legacy behavior to prevent flicker.

[Ottatop]

Currently, the compositor throttles cursor updates to ~24Hz for any fullscreen window to prevent VRR brightness flicker.

It's not to prevent VRR flicker. It's not even throttling, the cursor will refresh at above 24hz if the underlying content is refreshing at a higher rate. Rather, it's a baseline so the pointer actually moves when you move your mouse when nothing else on the screen is changing.

[anriha]

I assumed that the vrr flicker was the main concern, but if it isn't this makes more sense.

[Ottatop]

Thanks!