Reverts the temporary Chromium patch and restores the original macOS hit-test workaround behavior in Electron.

Co-authored-by: Charles Kerr <charles@charleskerr.com>

fix: simplify content_view_ hit-test transparency on macOS

Replace the RootViewMac-level TargetForRect override added in #51586 with
a DoesIntersectRect override on content_view_'s own targeter, restoring
the structure of #50330 but fixing its actual defect.

The original bug (#51576) was that ContentViewTargeterDelegate::TargetForRect
returned nullptr when no descendant covered the hit rect, violating the
ViewTargeterDelegate contract. RootView::UpdateCursor and
RootView::HandleMouseEnteredOrMoved dereference GetEventHandlerForPoint()
without null checks, so the nullptr crashed with SIGSEGV when a right-click
in a -webkit-app-region: drag region disabled the HTCAPTION early-exit.

re-implementing the parent targeter's child-walk loop so it could skip
content_view_ and return a sibling instead. That re-implementation duplicates
~25 lines of upstream logic with a subtle rounding divergence
(ToEnclosedRectIgnoringError vs ToEnclosingRect), and threads a new
content_view_hit_test_transparent_ flag through the platform-neutral
NativeWindow/BrowserWindow headers.

The same fall-through can be achieved with the existing hit-test hook:
override DoesIntersectRect on content_view_ to return false when no
visible, processable child intersects the rect. The parent's default
TargetForRect loop already skips children whose HitTestRect is false, so
hit-testing naturally continues to the WebContentsView sibling and resolves
to its NativeViewHost (kSubView) without ever returning nullptr from
TargetForRect or re-implementing the walk.

This reverts the NativeWindow flag, the BrowserWindow constructor change,
and the RootViewMacTargeterDelegate, leaving the fix entirely in
native_window_mac.mm at the same install site as #50330.

Co-authored-by: GitHub Copilot <copilot@github.com>