On Windows, fix deadlock caused by mouse capture (#1830)

The issue was caused by calling SetCapture on a window which already
had the capture. The WM_CAPTURECHANGED handler assumed that it would
only run if the capture was lost, but that wasn't the case. This made
the handler to try to lock the window state mutex while it was already
locked.

The issue was introduced in #1797 (932cbe4).

src/platform_impl/windows/event_loop.rs

@@ -1394,8 +1394,13 @@ unsafe fn public_window_callback_inner<T: 'static>(
         }
 
         winuser::WM_CAPTURECHANGED => {
-            // window lost mouse capture
-            subclass_input.window_state.lock().mouse.capture_count = 0;
+            // lparam here is a handle to the window which is gaining mouse capture.
+            // If it is the same as our window, then we're essentially retaining the capture. This
+            // can happen if `SetCapture` is called on our window when it already has the mouse
+            // capture.
+            if lparam != window as isize {
+                subclass_input.window_state.lock().mouse.capture_count = 0;
+            }
             0
         }