v3: Allow any process to steal foreground if there's no current foreground input. Allow children of the foreground process to steal foreground too, some user32:input rawinput tests need it.
Also add some dedicated window, which will get focused when none of the test windows are, to some ddraw and user32 tests calling `SetForegroundWindow(GetDesktopWindow())` and creating / destroying windows while processing X11 events [^1].
Regardless of the heuristics added here, it's not going to be possible to fully reliably tell between focus loss that are requested by a user action, and those which are simply caused by some window being destroyed, minimized or hidden.
We want to respect the user decisions above all, and prevent applications from stealing focus, so the tests need to be massaged to make sure they do not rely on getting foreground magically back after having lost it for good.
[^1]: It's not that much an issue if tests aren't processing events because they end up missing and batching host focus changes at once, and usually allow further SetForegroundWindow calls as the host restores focus to the new window automatically after their creation, but that's not a common use case.