Use a separate XfceDesktop widget/window per monitor

On Wayland, there is no standard way to place a single window/surface that spans all monitors. The layer-shell protocol, when not given a wl_output, will place in a compositor-dependent manner, but always only on a single monitor.

So this changes xfdesktop so each monitor gets its own XfceDesktop widget, which means each monitor will also get its own icon view widget when there's more than one monitor. This is the case for both X11 and Wayland, because having two different code paths for the two windowing systems would be silly and a pain. On Wayland, there is an additional wrinkle: since we want the backdrop drawn all the way to the screen edges, but want to honor the workarea when defining the area where icons are drawn, we have to put the backdrop and the icon view into separate layer-shell surfaces. The backdrop will have its layer-shell surface set to ignore exclusive regions, while the icon view's layer-shell surface will honor them.

The backdrop code has been nearly completely rewritten, since there was no way to use it as-is with the new model. Instead of being all object-oriented, there's now a single XfdesktopBackdropManager instance that finds and renders backdrops for monitor+workspace combinations, and tells the XfceDesktop instance how to draw it (for example, if the user has set the "span all monitors" option, it will render an image for the full spanned screens, and tell XfceDesktop what region to "cut" from the final image).

The icon view managers work a bit differently now. They maintain a single model that contains all possible icons, but then each monitor's icon view gets its own a GtkTreeModelFilter that wraps the main model, and filters out icons that don't belong on that monitor.

The minimized app icon manager has also been completely rewritten, as the monitor->workspace model previously present just didn't make sense anymore. A nice property of the new manager is that it fully supports the concept of having different workspace "groups" on different monitors, that can act independently of another (not a thing on X11, but Wayland's ext-workspace protocol supports it). A side-effect of all this is that minimized app icons will appear (initially) on the monitor where the window used to reside. I've also moved management of the window instances into the model, where this belongs; the manager was not the right place for it. I also just include every single window in the model, regardless of its state, and the per-monitor tree model filters make sure to only include minimized windows; it turns out this is much, much simpler than moving windows in and out of the model as they change state, and makes it easier to remember an icon's previous position on the screen between minimize -> restore -> minimize cycles.

The file icon manager has seen similar changes, though hasn't been fully rewritten, since there's a lot of code in there that would be error-prone to duplicate, and ends up being more or less the same code anyway. Enumeration and management of files on the desktop has been moved to the model, as (similarly to the window icon manager), that's really where it belongs. The model now contains all files on the desktop (hidden and not-hidden), all special files, and all volumes, regardless of what the various visibility settings are. Again, each icon view gets its own GtkTreeModelFilter instance (well, XfdesktopFileIconModelFilter instance), which filters out icons that shouldn't be visible. While this can require a little more memory than previously, it avoids constantly having to re-enumerate files on the desktop when something changes.

The file icon manager now has a new storage format for persisting icon positions. It's a YAML file now, and there's only one of them, rather than one for each workarea size. It has a separate configuration for each monitor, and monitors are tracked by (hopefully unique, hopefully stable) IDs as well as their geometry (not their workarea). The same config can end up being assigned to different monitors (though each plugged-in monitor must have a different config), which is useful if you (for example) use different physical monitors in different locations, but they have similar-enough resolutions. Xfdesktop will do its best to match an existing, unassigned configuration to a monitor it hasn't seen before, but if there are multiple decent possibilities, it will ask the user if they want to choose themselves (or if they want xfdesktop to just pick the best match). I've written migration code to migrate from the old icons rcfile to the new YAML file. This won't be perfect, since the configuration formats are sometimes hard to map one-to-one, but hopefully it should work most of the time for most people.

There are still some things I have yet to do (hence why this is still a draft):

• Rubberbanding across more than one monitor doesn't work -- I think this may just be how it will go, though.
• Moving file icons between monitors doesn't work (minimized app icons do, though).
• Context menus don't work on Wayland with the icon view enabled. The two-window setup means click events never make it to XfceDesktop, so nothing happens. Forwarding events might not be possible to do properly, because we can't tell the coordinate offset between the icon view's window and the desktop's window. Probably I'll have to "invert" things somewhat so the icon view can call down to XfceDesktop to pop up the menu on the icon view instead of the desktop.
• With 2 monitors, when switching from a mirrored setup to a non-mirrored setup, sometimes the mirrored monitor ends up with a backdrop covering only 1/4 of the screen.
• And I'm sure there are some things that are just buggy and don't work properly even though I've written the code for it. I haven't tested some of this (like the file icon manager or the position migration code) in a multi-monitor setup, and I haven't tested the icon view on Wayland at all.

I actually thought that list of broken things would be longer, huh.