Mac: Add more checks to diagnose move loop crash

Despite the expectation that capture has been turned off when we enter a
move loop, traces show that when the mystery move loop crash happens,
capture is indeed on.

Let's see if:
- Releasing capture actually works
- Whether we're succesfully releasing capture on the widget entering the
move loop, but still have capture on another widget.

Bug: 876493
Change-Id: I22db7aca92d25df9e97fd57f9b005b45770191b5
Reviewed-on: https://chromium-review.googlesource.com/c/1329903Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607230}

ui/views_bridge_mac/bridged_native_widget_impl.mm

@@ -681,8 +681,10 @@ bool BridgedNativeWidgetImpl::HasCapture() {
 }
 
 bool BridgedNativeWidgetImpl::RunMoveLoop(const gfx::Vector2d& drag_offset) {
-  DCHECK(!HasCapture());
   // https://crbug.com/876493
+  CHECK(!HasCapture());
+  // Does some *other* widget have capture?
+  CHECK(!CocoaMouseCapture::GetGlobalCaptureWindow());
   CHECK(!window_move_loop_);
 
   // RunMoveLoop caller is responsible for updating the window to be under the