state: fix unbound virtual modifier bug

state: fix unbound virtual modifier bug

Recent xkeyboard-config introduced the following line in symbols/level3:
    vmods = LevelThree,
However, the XKM format which xkbcomp produces for the X server can't
handle explicit virtual modifiers such as this:
https://bugs.freedesktop.org/show_bug.cgi?id=4927

So by doing the following, for example:

setxkbmap -layout de (or another 3-level layouts)
xkbcomp $DISPLAY out.xkb
xkbcomp out.xkb $DISPLAY

The modifier is lost and can't be used for switching to Level3 (see the
included test).

We, however, are affected worse by this bug when we load the out.xkb
keymap. First, the FOUR_LEVEL_ALPHABETIC key type has these entries:
    map[None] = Level1;
    map[Shift] = Level2;
    map[Lock]  = Level2;
    map[LevelThree] = Level3;
    [...]
Now, because the LevelThree virtual modifier is not bound to anything,
the effective mask of the "map[LevelThree]" entry is just 0. So when
the modifier state is empty (initial state), this entry is chosen, and
we get Level3, instead of failing to match any entry and getting the
default Level1.

The difference in behavior from the xserver stems from this commit:
acdad6058d52dc8a3e724dc95448300850d474f2
Which removed the entry->active field. Without bugs, this would be
correct; however, it seems in this case we should just follow the
server's behavior.

The server sets the entry->active field like so in XKBMisc.c:
    /* entry is active if vmods are bound */
    entry->active = (mask != 0);
The xkblib spec explains this field, but does not specify how to
initialize it. This commit does the same as above but more directly.

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