This changes the behaviour of the WIndows Pointer Input handling code. Instead of "ignoring" the pointer events and hoping that Windows will synthesize mouse events for us, we inject the mouse events into Qt directly, bypassing the OS. This mainly helps with Windows ver 1709 where touch events gets synthesized first instead of mouse input and causes weird behaviour.
This also makes it act a bit more like the WInTab mode, except that WinTab produces the synthesized mouse events not from Qt.
(See also: https://bugs.kde.org/show_bug.cgi?id=386476)
However, this exposes several issues within Krita:
1. Certain places in Krita rely on `QCursor::pos()` to get the cursor position. `QCursor::pos()` calls `GetCursorPos` WinAPI. Since Windows doesn't update the cursor position if the non-mouse pointer events are handled, certain elements would fail to follow the pen. (E.g. parallel ruler assistant: https://bugs.kde.org/show_bug.cgi?id=386475)
2. Since the mouse event is synthesized after the tablet event is sent, calling up the canvas popup palette would result in an unwanted click on the palette.