Draft: Add support for compositor handoffs

Upon encountering an error when dispatching or flushing because we lost connection (EPIPE or ECONNRESET) we attempt to reconnect to the compositor and reset our state to match from our existing knowledge of windows.

This can be used to make clients survive the compositor crashing or being manually restarted, improving overall robustness and reducing potential data loss.

To do this we cleanup all the globals and wayland objects, get a new registry and create them anew. After handling the globals in the display, the windows are reinitialized in the same fashion. Mostly we are able to hook into existing methods.

From a client POV input devices change, outputs change and windows are reconfigured, events client should be able to handle at runtime anyway.

SHM surfaces copy contents from the last backbuffers, OpenGL surfaces are regenerated, but the OpenGLcontext is not lost so all content remains.

---

This is unmergable in the current form due to unmerged dependencies libwayland and mesa.

https://lists.freedesktop.org/archives/wayland-devel/2021-August/041959.html XDC talk: https://media.ccc.de/v/xdc2021-18-addressing_wayland_robustness

It has been tested against gtk4-demo, rnotes and gnome-chess

libwayland: https://gitlab.freedesktop.org/davidedmundson/wayland/-/tree/reconnections mesa: https://gitlab.freedesktop.org/davidedmundson/mesa/-/tree/reconnect

Known caveats: - vulkan backend will not work without further mesa work - foreign transient parents will be lost (this could be addressed in the compositor with xdg-session) - any client code that uses low level libwayland will also need adjustment

This is uploaded now for early review and feedback.

Video in action: https://www.youtube.com/watch?v=eoDnWl6PjNs