reintroduce xwayland is_unmanaged

Created by: Ongy

https://github.com/swaywm/wlroots/pull/1145 removed the wlr_xwayland_is_unamanged function while fixing OR, because it was belieived that it's supposed to work around the broken OR handling.

This was a misunderstanding. is_unmanaged is (while sort of a hack) intended to work around inherent differences between "real" X sessions and our Xwayland/wayland situation.

The main reason it exists is to support applications like rofi and dzen, while not handing focus to other OR windows (which should not be required). Traditionally, these applications just grabbed input from X and didn't need to be focused by any logic in the WM. Which of course doesn't work in wayland compositors. So we have to give them focus in some way. Giving every OR window focus, breaks other applications that don't expect focus to change.

A testcase that was pointed out to me where wlr_xwayland_is_unamanged was breaking things is https://github.com/swaywm/sway/issues/2128 (syncplay, gitk, gitgui) Supposedly it broke using keyboard to navigate the menus. I can't reproduce this with this patch. The popups can be navigated as long as the parent has focus.

Testing: Requires to merge https://github.com/swaywm/wlroots/pull/1164 since Xwayland can't be used at all without.

As I hope the commit coment points out, this is a focus issue. With this patch applied, dmenu/rofi will work fine. I will retract (or improve) when I get a counter-example. @emersion you are up!

gitk is somewhat broken, but thats unrelated to this patch. (Moving cursor to different menu while menu is shown is funky)