Tests show this is just wrong. This patch fixes a regression introduced by
commit 74e3f516.

winemac: Send WM_{ENTER, EXIT}SIZEMOVE before/after window dragging and run an internal event loop during.

This simulates some of what would happen if user32 were managing the drag.  The
click in the caption would cause WM_SYSCOMMAND/SC_MOVE.  The processing of that
message is synchronous and doesn't return until the move is complete.

Some games require that "blocking" in the internal event loop to prevent them
from misbehaving during the drag.

winemac: While a window is being dragged, suppress mouse events and disable cursor clipping and warping.

This fixes a problem where some apps move their window to the front after
the user switches away to another app.  OS X prevents the background app
from actually coming in front of the active app's front window, but the
window gets ordered in second place, possibly obscuring other windows of the
active app.

Some Windows Media Player 9 visualization plugins used ddraw in this way
to get a dc for their custom memory allocations.