fix: child window alwaysOnTop level persistence

[codebytere]

Description of Change

Fixes an issue found while debugging #29732 - when a child window is attached to a parent NSWindow, the child window's level will be reset. E.g if one calls childWindow.setAlwaysOnTop(true, 'screen-saver'), this will not be honored. This fixes that by preserving the window level before it's attached to the parent and then restoring it.

Tested with https://gist.github.com/f2a3a5e8d9130223f18b8ddade390f20.

A test can't be added here because isAlwaysOnTop is true for all child windows, and while setAlwaysOnTop differentiates between different window levels the getter does not, and so it's not possible at present to tell whether or not a window level is for ex. screen-saver or pop-up-menu since isAlwaysOnTop would be true for both.

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 the setAlwaysOnTop value would sometimes not be preserved for child windows on macOS.

[nornagon]

should we make a getter to make this testable?

[codebytere]

@nornagon i considered that but i wasn't sure if we wanted to pursue that given that if we modify the existing isAlwaysOnTop getter that'd be semver-major, and a semver-minor change that would address this would be sort of strange given that we'd be adding basically another getter for alwaysOnTop information so we'd have one setter and two getters. We could potentially just leave it undocumented, but......that feels kind of janky 🤔

[nornagon]

I think it could make sense to add another getter for alwaysOnTopLevel (and maybe also for relativeLevel?)

I've also been considering a class of tests that could make use of desktopCapturer and uniquely-colored windows to test things like this (esp. been thinking of this for the pdf viewer). In that case, you could have a test that tested the outcome of the always-on-top-ness, rather than the values in memory, i.e. that the higher layer appears above the lower layer when they overlap, even when the lower-layer window is focused. Probably a bit much for this PR though.

[zcbenz]

We could potentially just leave it undocumented, but......that feels kind of janky 🤔

Another choice would be wrapping it in #if DCHECK_IS_ON() so it is only available when running tests. There are a few places using this pattern.

[codebytere]

@zcbenz @nornagon i added a new undocumented method getAlwaysOnTopLevel which enables testing as well as a test. Since the granular value set is really only relevant on macOS it's only defined there for now but in the future we could consider:

1. Documented and exposing this method in a follow-up semver-minor PR
2. Moving this to be defined only for testing builds as @zcbenz mentioned with a DCHECK_IS_ON guard as well as another potentially undocumented method for checking relative window level.

My goal for the new method i added here is to enable minimum viable testability more than anything else but I'm happy to modify this or take on item(s) numbered above if you all think that does fall within scope of this PR!

[release-clerk]

Release Notes Persisted

Fixed an issue where the setAlwaysOnTop value would sometimes not be preserved for child windows on macOS.

[trop]

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

[trop]

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

[trop]

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

[trop]

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

[trop]

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