wayland: ensure windows can be moved and resized if compositor is using CSD

[lukefromdc]

Ensure that nagivation and spatial windows can be moved and resized when running under wayland with CSD enabled, note that CSD is the default in many compositors and forced in some.

Also note that in wayfire, using CSD will pick up the GTK theme's decorations which will look like they do for windows that do not use headerbars (such as all MATE apps) in Mutter. This gives far better support for the MATE themes than firedecor or similar SSD decorators for wayfire. We read the port of the metacity theme to GTK and without a GtkHeaderBar we get normal titlebar theming and dimensions unless the theme itself has an issue.

[lukefromdc]

There is a "metacity decorator" for wayfire but at least Debian doesn't ship it and it's an early alpha right now.

[lukefromdc]

I will test moving those funcrions unconditionally. The use of a "constructed" block is according to the documentatiion meant for cases where something must br delayed, so my guess is that a long time ago this was needed. The libunique to GtkAppication port years ago used code from Nautilus 3.0, so my guess is in that era there was an issue. The reason I split the move of this out in a non-x11 only block was to minimize changes in the X11 session given limites testers. Simpler code and one less runtime check if we can do this unconditionally of course. I will be able to test that later today, if no surprises in x11 I will update this PR accordingly. If that acts up I can chexk for wayland explicitly instead.

[lukefromdc]

Latest force-push unconditionally removes the constructed() class and moves setting up bookmarks and initial geometry to the constructor() class unconditionally. No change in wayland behavior from the earlier version of this. A test in x11 also showed the bookmarks loading as before, and initial window geometry whether stored from last run or specified on the command line with the -g flag working the same as before. It thus appears we no longer need the constructed()class at all.

Removed it entirely: this simplifies the code, gives us one less include, and one less runtime check to deal with

[lukefromdc]

The Travis error is
#1790
which is another gem error on deployment that seems to be MATE-wide. As it is the deploy code affects only the Federa build. Debian build without the deploy code completed fine.