chore: throw an error when trying to subclass BrowserWindow

[codebytere]

Description of Change

Closes #41785.

Explicitly throws an error when users try to subclass BrowserWindow as it causes issues over the binding / lifecycle boundaries.

Also adds some tests.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• 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 BrowserWindow.getAllWindows() did not return subclasses of BrowserWindow.

[MarshallOfSound]

This has come up before (will find ref in the am) and this is intentional, subclassing any of electrons built-in classes is not supported and will cause various issues, mostly over the binding / lifecycle boundaries. I think we even explicitly document somewhere not to subclass our api

[codebytere]

ah gotcha - we should document that more visibly then i'd say as i checked around a bit and couldn't find anything in the ts commit history about intentionality of it

[nornagon]

We should probably make BrowserWindow's constructor throw if it's being instantiated as a subclass.

[codebytere]

@nornagon done - if you have a better idea of where I should throw let me know but trying in BrowserWindow::BrowserWindow via GetConstructorName() looked like it'd be a headache so i went with _init.

[nornagon]

Hm... I think this actually has to happen in C++. By the time _init is called, a bunch of BW initialization has already happened. And I don't think we correctly handle thrown errors in _init—we continue initializing the window regardless. I'm a little surprised the test passes!