[DONOTMERGE] wayland: Implement support for surface suspension

[flibitijibibo]

This is a patch to support proper window occlusion events with Wayland. It should NOT be merged until this protocol has been finalized:

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/99

[flibitijibibo]

We're approaching the 1-year mark and it seems like this protocol isn't going to happen, so I'm going to bail on this - this isn't strictly required in SDL since the driver is supposed to be doing the core of the work here, but from what I can tell it's something middleware vendors want but the protocols group 100% does not want. If this ever exists it will likely be a vendor-specific protocol from either wlroots or KWin, similar to the early server-side decoration protocol.

[flibitijibibo]

Today's wayland-protocols release includes surface suspension via an xdg_shell update, so this could be revived if anyone needs it.

[tokyovigilante]

Hi, I would be interested in this as I am trying to add SDL (and Dear IMGUI) as a UI library for a non-game app and am using a foreign event loop (libdispatch), as most of the time the app is playing audio and may wish to respond to key events on a device with the screen off, or on desktop with the UI hidden.

However this would also ideally have the entire SDL event management process be non-blocking (my current code is capable of monitoring FDs for events and triggering callbacks when received, so I'm having trouble integrating the SDL input events in particular from a somewhat inflexible while event = SDL_PollEvent()... type setup. I'd much prefer something like OnSDLEvent(callback) and if that is an input event, update my state, and if it is a Wayland frame callback, render the next UI frame.
[EDIT]: Actually it turns out that the new SDL3 callback entry points API and SDL_AddEventWatch` might be just what I need!