Mac: Release capture when running a move loop

This is a speculative fix for https://crbug.com/876493

There's an implicit but unenforced assumption that a widget doesn't have
mouse capture when a move loop runs. Indeed, all implementations of RunMoveLoop
besides Mac appear to do this directly or indirectly, and we even do a DCHECK
in BridgedNativeWidget to ensure this is the case.

As it happens, in most cases on Mac, this ends up being true by accident:
When detaching a tab into a new window, we attempt to acquire capture in
TabDragController::Attach, but fail because the window of the newly created
widget is not yet showing.

However, evidence from the field in the linked bug shows that in reality,
sometimes we *do* have capture while running a move loop. So at a minimum,
let's get our RunMoveLoop semantics in line with other platforms and see
what happens, though there's a lot of other stuff wrong with this situation
IMO.

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

ui/views/widget/native_widget_mac.mm

@@ -568,6 +568,7 @@ Widget::MoveLoopResult NativeWidgetMac::RunMoveLoop(
   if (!bridge_impl())
     return Widget::MOVE_LOOP_CANCELED;
 
+  ReleaseCapture();
   return bridge_impl()->RunMoveLoop(drag_offset) ? Widget::MOVE_LOOP_SUCCESSFUL
                                                  : Widget::MOVE_LOOP_CANCELED;
 }