QWindowsPipeReader/Writer notification stops when dragging the window

Removing of QWinOverlapperIoNotifier, based on IO completion ports [1], in favor to the alertable I/O functions [2], leads to stopping for all I/O in widget-based application, e.g. when the user holds a mouse button on the widget title.

For example, it concerned to the QLocal{Socket|Server} and QProcess classes. 

I have added two simple widget-based examples:

• localsocket.zip - demonstrates this issue, the user should run this example and try to hold the left or right mouse buttons on a window title (or just click on a window title with the right button when the title-context menu will be displayed). Then all I/O output will be stopped, until the user closes the context menu, or when releases a mouse buttons.
• tcpsocket - demonstrates the other behavior: during the holding of the left mouse button, the I/O still is running, but when holding the right button, it also stops.

Previously (when has been used the QWinOverlapperIoNotifier), the localsocket example had same behavior as the tcpsocket example.

Of course, seems, a workaround is that, the user shall move the QIODevice objects/workers to a separate thread. And I'm not sure if it is possible with the callbacks of {Write|Read}FileEx functions, I mean, that is it safely? Also, seems, it is completelly not an expected behavior, because the I/O should continue in a main thread anyway (if to think logically).

A main questions are:

1. What to do to users with such zoo in behaviors?
2. What to do to contributors (e.g. for me), e.g. should I introduce the alertable I/O and for qtserialport module too?

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx

[2] https://msdn.microsoft.com/en-us/library/windows/desktop/aa363772(v=vs.85).aspx