Fix overlay popup focus issues

[MrJul]

Note: #17322 should be merged first for tests to correctly pass. This PR is based on it. Merged

What does the pull request do?

This PR fixes several problems related to overlay popups:

• Key navigation didn't work inside them.
• For flyouts, the first control wasn't automatically taking the focus.

How was the solution implemented (if it's not obvious)?

A KeyboardNavigationHandler has been added to OverlayPopupHost, mimicking the behavior of a standard popup.
For this to work correctly, IInputRoot had to be implemented on OverlayPopupHost.

OverlayPopupFlyoutTests has been added, based on FlyoutTests but with overlays (3 failing tests before the changes).
PopupTests.Focusable_Controls_In_Popup_Should_Get_Focus was passing for wrong reasons: it didn't try to really move the focus. This test has been adjusted.

Remarks

Access keys still don't work in overlay popups after this PR. I'll fix them in another PR.

Fixed issues

• Fixes Tab Key Navigation not working when OverlayPopups is set to true #16077
• Fixes OverlayPopups is True affects the “down” key of the combox #17213

[avaloniaui-bot]

You can test this PR using the following package version. 11.3.999-cibuild0052765-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[avaloniaui-bot]

You can test this PR using the following package version. 11.3.999-cibuild0052774-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[maxkatz6]

Couldn't existing IFocusScope infra be reused here?

[MrJul]

Couldn't existing IFocusScope infra be reused here?

OverlayPopupHost is already a IFocusScope, so once focus is inside the popup, it already works correctly.

However, for key events to work, this requires the Popup itself to be attached to the visual tree.
In the flyout case, the Popup is created dynamically: its InteractiveParent is effectively null (which is correct). Events will stop there and won't bubble up to the parent window containing the KeyboardNavigationHandler.

Rather than hacking this, I chose to have the OverlayPopupHost use its own KeyboardNavigationHandler: this better matches what happens in the non-overlay case (with the PopupRoot having its KeyboardNavigationHandler).