Add preliminary Wayland support

Going to hold off on merging to master until after we branch for 4.18, as shipping this code would require libxfce4windowing to be considered API/ABI-stable, which I don't think will happen in such a short timeframe. Not to mention it's possible this MR introduces regressions that I haven't found yet.

This removes libwnck, and ports xfdesktop to libxfce4windowing, which is a libwnck-lite-workalike that abstracts between X11 (where it uses libwnck under the hood) and Wayland.

Some of this is just s/wnck/xfw/, but there are some important differences:

• Wayland's experimental workspaces protocol supports the concept of "workspace groups" that can have independent workspaces contained in them (I think the idea is that you could have completely different sets of workspaces on different monitors, if you wanted to). X11 does not have this concept, but libxfce4windowing models the group behavior, and maintains a single dummy workspace group on X11. xfdesktop handles multiple groups in a somewhat naive way, and some behaviors aren't perfect, but supporting multiple groups properly would likely require a bit of a refactor.
• While we're on the topic of workspaces, on X11 you really only have the ability to add a new workspace onto the end, or remove the last workspace (well, presumably a WM could support something more advanced, but libwnck doesn't consider that possibility). On Wayland, arbitrary workspaces can be removed. The new code supports this new paradigm, but it's unclear how it will behave in practice.
• Some things are just not available on Wayland, like setting xfdesktop's window ID as a property on the root window so other applications can discover it.
• Wayland's foreign-toplevel protocol and workspaces protocol do not interact at all, so there is no way to know which windows are on which workspace. That means we can't move windows between workspaces (or pin/unpin) or meaningfully list them in a window list organized by workspace. We also can't determine the window stacking order on Wayland.
• Wayland's foreign-toplevel protocol does not support some actions like triggering keyboard move or resize, or the always-on-top state.
• xfdesktop requires the Wayland layer-shell protocol; otherwise the desktop window will end up stacked with regular application windows.
• ... there are probably more things that I've forgotten.

There will need to be a bunch of discussions with the Wayland community (more likely, the wlroots-supporting community) in order to bring feature parity up to what we can do on X11. Alternatively, if xfwm4 ever becomes a fully-functional Wayland compositor, we can go our own way and develop our own protocol extensions, at the expense of our components not really working properly on a different compositor.

At any rate, behavior on X11 should remain the same; any deviations should be considered regressions.