QtQuick: Focus changes on mouse down/up breaks mouse event routing

There are somewhat different symptoms on Windows and Mac, therefore we attach two repros to this ticket, but logically they are almost identical. In either case we log the mouse events from one or two different QQuickWindows into stdout (make sure you have a console window open). The mouse event log messages are having the format "<qtWindowID> messageText <counter>", where qtWindowID is 1 for main Qt window and 2 for the modal dialog's Qt window (in case one is created), and the counter simply increments to help seeing that the messages are coming.

On Windows:

1. Focus release on mouse down
   Run the repro. A native WinAPI window with an embedded Qt window opens. Watch the mouse hover events as you move the mouse around the window. Left-click (at this point the app will give the focus away to the parent window, see the line 52 in the source file) and hold somewhere within the painted figure. Watch the mouse down event being logged. Release the mouse. Watch that the mouse release event is not being logged, since it does not come. Expected behavior: mouse release event comes.
2. Implicit focus release due to creation of a modal dialog on mouse down
   Same as the first scenario, but switch the #if in line 51 from 1 to 0. Now instead of releasing the focus, the app will create a modal dialog (with an embedded Qt window) on mouse down. Try the same steps and watch the mouse release even not coming either. Expected behavior: mouse release event comes.

For us it is absolutely essential that the release event is coming in this case. It was coming in the previous non-Qt version of our code, where the event was coming from the OS (directly, or indirectly, after translation from other events, like lost mouse capture), after switching to Qt we don't get it anymore and this leads to stuck GUI elements (like buttons).

On Mac:

1. Opening a modal dialog on mouse up
   Do the same steps to open the dialog. Here we open the modal dialog on mouse up instead of on mouse down. After the dialog is open, move the mouse around over both windows. Notice how all hover events arrive in window 1, regardless of where the mouse is. The situation is fixed after clicking into the dialog once. Expected: when the mouse is over the dialog, the hover events are expected to arrive in the dialog. Whether we still expect to receive hover events in window 1 is open for debate.
2. Opening a modal dialog on mouse down
   Change the constant OnMouseDown in line 18 to 1. Now the dialog will be open on mouse down. The hover events are now correct, but the mouse up event didn't come - same problem as on Windows. (You can also try setting the constant RunDialog in line 21 to 0, which will release the keyfocus instead of running the dialog, however, differently from Windows, this doesn't seem to cause problems on Mac).

The incorrect routing of mouse hover events is also important for us, since we use hover events for GUI highlighting and currently the GUI highlight happens in a totally wrong window at a totally wrong position.

NB. We wonder if this is also related to https://bugreports.qt.io/browse/QTBUG-107994