QDockwidget screen change issue(s) more involved parts.

Qt Gui with high dpi has improved a lot recently, but there are still a few annoyting issues, where this is one of them ... (where persons with deep insights into widget/ui)

Steps to reproduce:
1) Have a system setup like mine - se attached qtdiag.txt
(In short it means have a 4K screen on the left and a non 4K on the right)
2) Run the attached code.
3) Slowly move the dock widget from the left screen to the right. When it flickers move back (repeat)
4. The size of the dock widget is changed and repeating can make it extremely oversized
5. Flicker can also occur (see attached video)
( 6. Notice that even a fast move (that often will 'avoid' this issue) STILL has too many screen changes. We expect one but get 3.)

It should be noticed this happens for more reasons together being problematic:

• The dock widget has a title and is therefore not a native window with a window title.

• The screen on a system is not a single coordinate systems, but instead two
  "DISPLAY2" QRect(0,0 2560x1440) dpr: 1.5 (left)
  "DISPLAY1" QRect(3840,0 2560x1440) dpr: 1 (right)
  (which also gives horrible headaches if we try to manually implement such a move - like we do in QDockWidget).
  Maybe it should be changed so we actually have a single true coordinate system? (maybe by adding new functions and make use of thoese?).
  (A I added GUI as a component and not just Widgets)

• Also there is no (easy) way to convert a point from the one coordinate system to the other, but it is maybe what we want to?
  When the widget changes screen it position should maybe also be updated to be on the display it is actually shown on...
  (A I added GUI as a component and not just Widgets)

• If we move the widget a single pixel (e.g to the right - and more onto the new screen), Qt instantly considers the widget to be put back on the old screen before it again will move it back to the new one. Maybe we have something breaking mechanism so it won't end on the (in both way) right screen afterwards. A solution could maybe be to be more intelligent here because this point is closer to the center than the old point, so why move it back when the previous move actually caused it to be placed there?