fix: propagate window.open settings to child window

[VerteDinde]

Description of Change

In #24517 and #28518, as part of adding the new setWindowOpenHandler API, we refactored the _callWindowOpenHandler method to pass in additional details and make it more compatible with the new API standard, setWindowOpenHandler. However, this also broke how feature details were passed into new child/guest windows, specifically ones still using window.open - if a window was not opened with an existing windowHandler, all child window constructor options would automatically return null, hitting this check.

In Electron 14 and 15, two things changed: 1) child windows no longer inherit their transparency settings from parent windows, and 2) our previous default if no background color exists, SKColor_TRANSPARENT was converted to an optional value absl::nullopt, which defaults to white. Thus, this bug suddenly surfaced for child windows opened with window.open.

This PR allows child windows to fall back on the parsed features to correctly read transparency, background color, etc, until the window.open event is removed.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is 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 child windows not inheriting the correct transparency and background color settings.

[release-clerk]

Release Notes Persisted

Fixed child windows not inheriting the correct transparency and background color settings.

[trop]

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

[trop]

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