Fix dialog losing focus when changing WindowState

[corvinsz]

fixes #3434

The fix is basically to listen for the StateChanged event of the parent Window.
If the window is restored from the minimized state, we focus the previously focused element, which got stored in a field _lastFocusedDialogElement when the window got minimized.

I want to point out the artificial delay I added, that we have in other places in the DialogHost class too. I just couldn't get it to work without the (50ms) delay, as described in my comment above the "hacky" code.

...
// Kinda hacky, but without a delay the focus doesn't always get set correctly because the Focus() method fires too early
Task.Delay(50).ContinueWith(_ => this.Dispatcher.BeginInvoke(DispatcherPriority.Background, new Action(() =>
...

[corvinsz]

It seems like there is a problem with running the tests via github actions. This PR just had another failing test (SplitButton_WithButtonInPopup_CanBeInvoked). When reran, the test passed.
I'm not sure if this is a TUnit or github actions problem?

I had the same issue in #3915

[corvinsz]

Discussion on how to get the last focused element

[corvinsz]

I also adjusted the test to test against both DialogHost styles. I would say this problem is worth testing for both styles.

[Keboo]

So the issue with the test should be resolved if you rebase on the latest main. I believe I fixed that test last week.

On the note of focus, I think we want to use the Keyboard Focused element rather than the logically focused element. The problem with the current events, is that Windows will have removed the keyboard focused element by the time those events are raised. After a little testing I think that we can watch one of the WND_PROC messages to know when a minimize is about to occur, and capture the element with keyboard focus then.

private void ListenForWindowStateChanged(Window? window)
{
    if (window is not null)
    {
        if (PresentationSource.FromVisual(window) is HwndSource source)
        {
            HwndSourceHook hook = Hook;
            source.AddHook(hook);
            //TODO: Need to unregister hooks as well, and ensure we don't double register
        }

        IntPtr Hook(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
        {
            //https://learn.microsoft.com/en-us/windows/win32/menurc/wm-syscommand
            const int WM_SYSCOMMAND = 0x0112;
            const int SC_MINIMIZE = 0xf020;
            switch (msg)
            {
                case WM_SYSCOMMAND:
                    if (wParam.ToInt64() == SC_MINIMIZE && //Minimize
                        _popupContentControl?.IsKeyboardFocusWithin == true) //Only persistent the one with keyboard focus
                    {
                        var element = Keyboard.FocusedElement;
                        //TODO: Perist keyboard focused element
                    }
                    break;
            }
            return IntPtr.Zero;
        }
    }
}

This code still has the TODOs that would need to be addressed, but this way we can rely on looking at keyboard focus to see which element we care about.

[corvinsz]

I implemented the changes as you suggested. From my manual testing it works fine, however the UI test I added is failing.
I haven't yet figured out why it fails.

Edit: I'm starting to think you can't properly debug the tests. If I place a breakpoint in the switch statement inside of the Hook method, it is never hit. When testing manually it is being hit.