fix: restore original draggable regions behavior pre-35603

[MarshallOfSound]

Reverts three PRs so that we can restore the old draggable regions behaviour.

• refactor: use views NonClientHitTest for draggable regions on mac #35603
• refactor: move draggable regions to WebContents #36230
• fix: resizing borders in nondraggable regions #37016

Notes: no-notes

[nornagon]

reverting not necessary; discovered that new impl is correct.

tldr: previously, -webkit-app-region: no-drag would "shine through" -webkit-app-region: drag. it no longer does. hacks that apps used to work around that bug may now be presenting as bugs, but these should be fixed on the app side.

[codebytere]

@nornagon can you please comment on the open bugs then? there are several:

• [Bug]: Drag region continues eating events when set to unset or no-drag #37137
• [Bug]: Draggable regions prevent webContents interaction with customButtonsOnHover  #37210
• [Bug]: context menus cannot be displayed when "-webkit-app-region: drag" is enabled #37301

I'm also not sure I agree this is working as expected - take #37301. In Chromium, it's quite possible to open a context menu in the toolbar:

where i can also drag.

[nornagon]

@codebytere done. #37137 is a duplicate of an older bug (#32341), that one is gnarly and can't be fixed without some serious hacking in Blink. It's a Chrome bug, not (just) our bug.

#37210 is WAI, the old behavior was buggy.

#37301 is a real bug, I opened #37386 to fix it.

[codebytere]

ty! is #32341 open as a crbug anywhere? i'd prefer to kick it up there where possible 😅