ipc: Add idle and keyboard shortcuts inhibitor events

[michaelweiser]

As discussed in #5124 and #5324 I would like to react to status changes of both idle and keyboard shortcuts inhibitors by giving some (visual) feedback to the user. An external script monitoring window property changes via ipc was identified as preferred solution in #5323. Idle inhibitor status was added to get_tree output in #5307.

This PR attempts to add the following additional functionality:

• add keyboard shortcuts inhibitor status to get_tree output per container as "keyboard_shortcuts_inhibitor": "none|inactive|active", reflecting presence and current state of any applicable inhibitor. Shortened example get_tree output:

                {
                  "id": 12,
                  "type": "con",
[...]
                  "inhibit_idle": false,
                  "idle_inhibitors": {
                    "user": "none",
                    "application": "none"
                  },
                  "keyboard_shortcuts_inhibitor": "none"
                },

• add and emit new events on status changes of idle and keyboard shortcuts inhibitors. Structure:
  • idle inhibitor:

{
  "change": "create|mode|destroy",
  "idle_inhibitor": {
    "active": true|false,
    "type": "application|user",
    "mode": "<standard user inhibitor mode description>",
    "container": {
      "id": 34,
      "type": "con",
[standard container description]
      "inhibit_idle": true,
      "idle_inhibitors": {
        "user": "<previous state[1]>",
        "application": "<previous state>"
      },
[...]
    }
  }
}

• keyboard shortcuts inhibitor:

{
  "change": "create|activate|deactivate|destroy",
  "keyboard_shortcuts_inhibitor": {
    "container": {
      "id": 34,
      "type": "con",
[standard container description]
      "keyboard_shortcuts_inhibitor": "<previous state>"
    }
  }
}

Example subscribe command: swaymsg -t subscribe -m "['idle_inhibitor','keyboard_shortcuts_inhibitor']".

[1] showing previous state in the container description is a side-effect of event send and object update ordering which seemed nice to have if available for no cost. It does not work for attribute changes (such as the user inhibitor mode) though because those are updated in-place. Guidance if this is desirable at all would be helpful. My use-case actually only needs the container id.

Rationale for adding new events instead of adding more events for affected objects:

• efficiency: clients would need to subscribe to e.g. all window change events even if only interested in inhibitors
• interface overload: inhibitors would require sub-event types for window changes, e.g. idle_inhibitor::create, suggesting a conceptual mismatch
• extensiblity: if the next user wants to (additionally) refer to the seat or output affected by an inhibitor this information could potentially be added to the per-inhibitor events instead of adding more events for the other object classes