Add Wayland docking support

[mliberty1]

Thanks for your great work on Qt-ADS! I have been using it in the Joulescope UI for many years, and it has been excellent. I have a number of customers affected by my UI issue #316, poor Wayland support. I tried to get someone on Upwork to fix this, but failed. Today, I worked with Claude Code / Fable to get this done.

This PR is a self-contained fix for Wayland. It's hopefully relatively easy to accept since most changes are gated to only affect Wayland. It does touch a bunch of files, though. The addition of GlobalPos parameter to a few methods should be a flow-through no-change on other platforms.

The overall experience is functional, but definitely not as slick as Windows and macOS. However, functional is an improvement and good enough to address my customers' concerns about slow performance using xcb.

Curated AI-generated summary follows:

Summary

This PR adds support for docking (undocking, moving, and re-docking floating widgets) on Wayland. It implements the approach outlined in #714 and follows the same mechanism that Qt itself uses for QDockWidget/QToolBar on Wayland.

Wayland forbids the techniques the docking system relies on elsewhere: a client cannot move its own top level windows in screen coordinates, cannot query the global cursor position, and cannot position one top level over another. Instead of the mouse tracked drag preview, undocking now performs a compositor driven drag:

• Floating containers always use native window decorations on Wayland, so the compositor moves the window (the custom QWidget title bar cannot).
• Undocking executes a QDrag carrying the MIME types that QWaylandDataDevice translates into an xdg_toplevel_drag_v1 request, so the real floating window follows the cursor (no translucent preview).
• CDockContainerWidget accepts drops and drives the drop overlays from the drag-and-drop event positions instead of QCursor::pos(), which is stale during a drag on Wayland.
• Dragging the tab or dock-area title bar of a floating widget drags the existing floating window, so it can be docked back into another container.

Platform impact

Every change is guarded by a new ads::internal::isWayland() helper, so X11, Windows and macOS are unaffected. Where a function is shared (e.g. the drop overlay setup, now factored into CDockContainerWidget::showDropOverlays()), the behavior is preserved on the other platforms. I verified the X11 mouse-drag path still works unchanged.

This change is self-contained and does not depend on any other PR. On the non-Wayland paths the existing top-level Qt::Tool overlays are kept exactly as before; only on Wayland are the overlays child widgets.

Requirements and behavioral notes (also updated in README)

• Requires Qt 6.6.3+ for the xdg_toplevel_drag_v1 support; on older Qt the code is harmless but the window will not follow the cursor, so X11/XWayland is still recommended there.
• On Wayland: native decorations only (no custom title bar), the real window is dragged instead of a translucent preview, a floating window takes the dock manager's stylesheet when it is created (a later application-wide stylesheet change does not update an already-floating window), and the compositor owns window stacking (no forced stays-on-top).

Testing

Tested on GNOME / Mutter 50.1 with Qt 6.11 (PySide6): undock, move via the decoration, drop on an indicator to re-dock, drop outside to keep floating, re-dock a floating window via its title bar, floating-to-floating drop, and auto-hide undock. The X11/xcb path was regression tested and is unchanged.

Other compositors are not yet covered; on KDE/KWin a benign Qt warning (This plugin supports grabbing the mouse only for popup windows) is emitted by Qt's own drag-and-drop internals and does not block docking.

References

• Addresses Support floating docks on Wayland #714 (Support floating docks on Wayland).
• Wayland: render drag preview and overlays as child widgets instead of top-level Qt::Tool #837 proposes rendering the drag preview and overlays as child widgets on all platforms. This PR is independent of it: it keeps the existing top-level overlays on X11/Windows/macOS and only uses child-widget overlays on Wayland.
• fix docking drag drop problem on Linux wayland #789 is an earlier workaround attempt for the same problem.