Make focusing newly mapped views optional (strict focus stealing prevention)

[dkondor]

Also continuation of #2527 and #2626, creating a (mostly) complete solution for focus stealing prevention.

This adds an option (core/focus_on_map) that determines whether newly mapped (opened) views are focused. The default is true which keeps the current behavior (as I imagine the newly introduced behavior would be too restrictive for most users). When set to false, views must explicitly use the xdg-activation protocol to gain focus, even when first mapped.

This PR is organized into 4 parts:

• commit d3c872b is just the same as xdg-activation: add focus stealing prevention when using tokens #2626 (as I don't think there is much sense in merging this only)
• the next two commits (b29982f and 95ebff8) implement this option
• commit 65a1338 adapts xdg-activation to be able to focus newly mapped views with a valid token
• the last two commits (e7af908 and 228478f) generate and pass valid tokens to commands that are run by Wayfire, so that when starting GUI apps, they can still receive focus

This is currently a draft, since some functionality is still missing:

• The main issue is that currently, newly mapped views are still stacked on top, but do not receive keyboard focus; ideally, they would be stacked below the currently active view, but I haven't yet figured out how to do this.
• From a UI perspective, I actually don't like putting this option in core. it would be nice to collect all focus stealing / activation related options in one place (i.e. with xdg-activation); however, since this option needs to be accessed from core, I don't like the idea of putting it under a plugin. Maybe an alternative would be introducing one more signal, but that also sounds overkill.
• Also, I'm unsure if this handles XWayland views correctly; I'm wondering if I should prevent focus here as well; in any case, I haven't tested with XWayland yet, but will do so next.
• I'll need to do more testing, but potentially I want to separately track the active view for normal and self-generated tokens (my main concern is that some commands will not result in a new view opening, so they should not invalidate normal tokens, but this is of course and edge case).

[killown]

I think it's easier with python and a few lines:

from wayfire import WayfireSocket
sock = WayfireSocket()
last_focused_view_id = sock.get_focused_view()["id"]

sock.watch(["view-mapped", "view-focused"])


def should_continue(msg):
    if "view" in msg:
        if msg["view"] is not None:
            if msg["view"]["role"] == "toplevel":
                return msg["view"]
    return None


while True:
    msg = sock.read_next_event()
    view = should_continue(msg)

    if view is None:
        continue

    if msg["event"] == "view-mapped":
        sock.set_focus(last_focused_view_id)
    if msg["event"] == "view-focused":
        last_focused_view_id = sock.get_focused_view()["id"]

[ammen99]

I think it's easier with python and a few lines:

from wayfire import WayfireSocket
sock = WayfireSocket()

last_focused_view_id = sock.get_focused_view()["id"]

sock.watch(["view-mapped", "view-focused"])

while True:
    msg = sock.read_next_event()
    if msg["event"] == "view-mapped":
        sock.set_focus(last_focused_view_id)
    if msg["event"] == "view-focused":
        last_focused_view_id = sock.get_focused_view()["id"]

While this is a good workaround in practice, we still switch the focus and then back. Depending on the app, this might not be what we want.