compat: separate ctx

Same as was done for types.

Signed-off-by: Ran Benita <ran234@gmail.com>
symbols: separate ctx

Same as was done for compat and types.

Signed-off-by: Ran Benita <ran234@gmail.com>
Add struct xkb_mod_set

The only thing that the compilation phase needs the keymap for currently
is for access to the modifier information (it also modifies it in
place!). We want to only pass along the neccessary information, to make
it more tractable and testable, so instead of passing the entire keymap
we add a new 'mod_set' object and pass a (const) reference to that.
The new object is just the old array of 'struct xkb_mod'.

Signed-off-by: Ran Benita <ran234@gmail.com>
text: take xkb_mod_set instead of the entire keymap

The modifier printing functions only need the modifier information, they
don't care about keys or leds, etc.

Signed-off-by: Ran Benita <ran234@gmail.com>
expr: take xkb_mod_set instead of the entire keymap

The modifier-resolving functions only need the modifier information.

Signed-off-by: Ran Benita <ran234@gmail.com>
action: take xkb_mod_set instead of the entire keymap

A couple of modiifer actions need this information, but not the entire
keymap.

Signed-off-by: Ran Benita <ran234@gmail.com>
vmod: take xkb_mod_set instead of the entire keymap

This is the only place where the modifier information is modified. We
will make it local to a given XKB file (after which it will be merged
into the keymap). Currently it changes the keymap directly, which
sidesteps the abstraction and leaves side-effects even if the XkbFile's
compilation fails.

Signed-off-by: Ran Benita <ran234@gmail.com>
compat: use xkb_mod_set instead of entire keymap

Signed-off-by: Ran Benita <ran234@gmail.com>
types: use xkb_mod_set instead of entire keymap

Signed-off-by: Ran Benita <ran234@gmail.com>
wip: symbols: use xkb_mod_set instead of entire keymap

TODO: partially revert 3abfe83e113e8abe28b044026cbd1fb34e9a4818 so the
we don't need access to the aliases until copying to the keymap.
Or just pass the aliases..

Signed-off-by: Ran Benita <ran234@gmail.com>