actions: Add support for multiple actions per level

[wismill]

This makes 1 keysym == 1 action holds also for multiple keysyms per level.

The motivation of this new feature are:

• Make multiple keysyms per level more intuitive.

• Explore how to fix the issue with shortcuts in multi-layout settings (see the xkeyboard-config issue).

  The idea is to use e.g.:

  key <LCTL> {
        symbols[1] = [ {Control_L,                  ISO_First_Group    } ],
        actions[1] = [ {SetMods(modifiers=Control), SetGroup(group=-4) } ]
  };

  in order to switch temporarily to a reference layout in order to get the same shortcuts on every layout.

  See the xkeyboard-config MR “Add option shortcuts:qwerty”.

This is quite a big change, because it breaks the design “1 action per level”.

This is WIP because there might be lots of corner cases.

I will try to break this into smaller commits, although the nature of the change makes it difficult to have smaller commits that compile.

Fixes #486

---

TODO:

• Fix remaining TODO/FIXME in the code
• Log entry

[wismill]

Rebased and split commits (a bit). The first commit should be dropped when #507 #516 is merged.

[wismill]

This new feature can be of help for shortcuts-related issues, such as: “Switching layout temporarily while modifier is held”.

For example, using:

    key <LCTL>               {
        symbols[1] = [       {Control_L,                             ISO_First_Group } ],
        actions[1] = [       {SetMods(modifiers=Control,clearLocks), SetGroup(group=-4)}]
    };

and setting keymap RANGE_REDIRECT to 0, every shortcut involving <LCTL> will use the first layout. The RANGE_REDIRECT and -4 are necessary because of how effective group computation works: it’s an addition of the various components (base, latched, locked), so SetGroup(group=1) does not set the effective group to 1.

That said, modifying actions in symbols is not really practical. But interpret statements only support one action and it is probably better so: we want to keep 1 keysym = 1 action.

We could, however, introduce “composite” actions, e.g. RunSequence(action1(…), actions2(…), …) (probably better with an array syntax). It would still count as a single action while parsing.

But in the end, I think we need a dedicated feature that:

• Add additional action to modifiers automatically;
• Handle the effective group computation properly;
• Maybe act differently if the non-modifier keysym of the shortcut is a (Latin) letter or not.

This would only internal with no special syntax, but a specialized API.

[wismill]

Rebased and added exhaustive tests, that enabled to discover some memory issues. We now disallow mixing multiple modifiers or group actions, as it requires to update state handling. I may add it in this PR if it is easy enough, else will do in a further MR/release.

macOS CI is becoming very slow and fails. Looks like some issues with packaging. I do not think we had a full xorg server installed there, but now it does.

[wismill]

Rebased to fix macOS CI.

[wismill]

Rebased after merging #526.

[wismill]

Note to self: we may want to merge #518 and #519 before this one. Or the contrary, whatever is easier.

[wismill]

Rebased after merging #519.

[wismill]

Rebased after merging #518.