fix: webContents interaction with draggable BrowserViews

[codebytere]

Description of Change

Closes #26355.

Fixed an issue where some buttons were un-clickable in some BrowserViews with draggable regions enabled.

This was happening because the way we construct draggable regions in BrowserViews is different than what we do in BrowserWindows - we implement them in the former by creating a new draggable NSView and overlaying regions that are not draggable. To accomplish this, we need to hitTest the view, so we can perform the correct actions when a user mouses down and tries to drag. Chromium explicitly chooses to ignore mouse events in RenderWidgetHostViewCocoa when another view has returned itself in the hitTest, which is the case here and the root of the bug.

To fix the issue resultant of the above, we explicitly need to tell Chromium that it should not use its own mouse ignore logic if a NSEventTypeLeftMouseDragged or NSEventTypeLeftMouseDown event - it should first check to see if we've told it not to do that and then proceed accordingly.

Tested with https://gist.github.com/060ad478da5b628726da4b4ea94a16a6.

cc @MarshallOfSound @zcbenz

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed an issue where some buttons were un-clickable in some BrowserViews with draggable regions enabled.

[zcbenz]

Did some testing and could not find any problem with this approach.

[release-clerk]

Release Notes Persisted

Fixed an issue where some buttons were un-clickable in some BrowserViews with draggable regions enabled.

[trop]

I was unable to backport this PR to "10-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I was unable to backport this PR to "9-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "11-x-y", please check out #26528

[trop]

@codebytere has manually backported this PR to "9-x-y", please check out #26745

[trop]

@codebytere has manually backported this PR to "10-x-y", please check out #26744