make bauhaus popups work with wayland

[dterrahe]

Bauhaus is one of the aspects of dt that has problems with running under pure wayland (instead of Xwayland; so starting with GDK_BACKEND=wayland). The issue is that under wayland it is no longer possible to reposition (popup) windows or to request their location and determine if they are partially outside the monitor workarea. Bauhaus comboboxes want to relocate the window when the selected value changes (for example by scrolling), so that the mouse is again over the selected value, or when the mouse approaches the screen edge and part of the list is obscured.

We also want to make sure the popup doesn't appear partly off the right or left edge of the screen. Gtk3 on wayland only supports gdk_window_move_to_rect to force a popup window to appear within the workarea. To simulate moving-when-scrolling this PR creates a very tall popup and draws its content depending on the current offset of the top item. The rest of the popup is left transparent (which wayland composites correctly). To determine how much of this column is off the screen (and therefore cut off) it catches the "moved-to-rect" signal that wayland uses to return this information. To see what this looks like run under normal X/Xwayland but comment out the if(GDK_IS_WAYLAND_DISPLAY line; the whole column will appear in black.

To avoid completely separate code paths this PR uses the same approach under x/osx/windows. But since some of these (at least x/xwayland) don't support transparent windows, the window is (re)sized to exactly match the popup, depending on how much was cut off at the screen edge (and would appear again on-screen after any move). Nothing should visually change on these other platforms. I've tested x and windows to some extent but rely on others to test Apple. And testers with multi-monitor setups are always especially appreciated.

This also fixes positioning of bauhaus widgets in the preferences dialog (where they are used since #15285). Under wayland their location was determined relative to the dialog top-left, but they were then placed relative to the main window top-left.

Something similar happened with bauhaus widgets in popovers (for display profiles and grids for example). Under wayland these are separate top level windows, but gtk3 fudges gtk_widget_get_toplevel to return the main window (and all offsets end up wrong). Now using gdk_window_get_toplevel which is as yet unfudged. This same complication might be the cause that under wayland the tooltips for these widgets end up too far to the left (but at the correct height...). I'm hoping that this issue will be fixed in gtk3 itself at some point (which could then cause trouble with any workaround I might put in place now).

This PR also fixes an issue that bauhaus popups since #14991 are handing off unhandled events to the shortcut system. While the preferences dialog is open this could have undesirable results, so this now only happens when the widget is in the main window.

Also removed double (triple) buffering in _popup_draw which is handled by Gtk since version 2.

EDIT: wayland creates a problem with opening a popup window while a tooltip is being shown. The tooltip is treated as a separate top-level window so the popup cannot be made transient for the "underlying" main window. This PR forces the tooltip to close first.

This doesn't solve all problems with wayland. Color management is the one brought up exhaustively. But when eventually wayland provides all the functionality we need and xwayland starts falling behind because fewer application will resort to it and distros focus on the more common experience, then we'll need/want to have made a start of tackling the issues that are really only on our side.

[TurboGit]

@dterrahe : I have tested this a bit and found that whatever the color theme used the bauhaus popup for sliders is always having the dark theme background.

[TurboGit]

CSS color needs some work.

[TurboGit]

Manually merged.