The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
MetaWindowXwayland derives from MetaWindowX11 to allow for some Xwayland
specific vfunc that wouldn't apply to plain X11 windows, such as
shortcut inhibit routines.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
For Wayland, we want to have everything possible in terms of the frame
rect, or "window geometry" as the Wayland protocol calls it, in order
to properly eliminate some flashing when changing states to fullscreen
or similar.
For this, we need to heavily refactor how the code is structured, and
make it so that meta_window_move_resize_internal is specified in terms
of the frame rect coordinate space, and transforming all entry points
to meta_window_move_resize_internal.
This is a big commit that's hard to tear apart. I tried to split it
as best I can, but there's still just a large amount of changes that
need to happen at once.
Expect some regressions from this. Sorry for any temporary regression
that this might cause.
This is specifically about managing X11 windows, not necessarily
running as an X11 compositor. By that I mean that this code is
still used for XWayland windows, and event handling is still and
modesetting / monitor management is still in core/.
This is also a fairly conservative move. We don't move anything
like screen.c or bell.c in here, even though those are really
only for X11 clients.
