The ForwardKeyEvent ibus signal is used to maintain ordering between CommitText events and non-IME key events.
The ordering is important for Korean IMEs, where it automatically commits text whenever a character is fully composed. This is different from Chinese/Japanese IMEs, where user manually presses a key to commit each word.
Without this patch, kitty can't handle non-IME key events when used with ibus-hangul, which utilizes ForwardKeyEvent signal.
Without ForwardKeyEvent:
```
key | sequence of events from application's view
r | UpdatePreeditText 'ㄱ'
k | UpdatePreeditText '가'
1 | (receives the reply to ProcessKeyEvent call: "native_key: 0x31 release: 0 handled: 0")
| -> UpdatePreeditText ''
| -> CommitText '가'
```
Application receives "1가", which is incorrect.
With ForwardKeyEvent:
```
key | sequence of events from application's view
r | UpdatePreeditText 'ㄱ'
k | UpdatePreeditText '가'
1 | (receives the reply to ProcessKeyEvent call: "native_key: 0x31 release: 0 handled: 1", and kitty discards the event)
| -> UpdatePreeditText ''
| -> CommitText '가'
| -> ForwardKeyEvent keysym=0x31("1")
```
Application receives "가1", which is correct.
Relevant ibus-hangul github issue to implement ForwardKeyEvent: https://github.com/libhangul/ibus-hangul/issues/42
Relevant changes in Qt to handle ForwardKeyEvent: https://codereview.qt-project.org/c/qt/qtbase/+/212179, https://codereview.qt-project.org/c/qt/qtbase/+/255587
Now pressing a modifier key in one keyboard and a normal key in another works. Fixes#2362
Don't rebuild keymaps on new keyboard events that only change geometry. Fixes#2787
Better handling of multiple keyboards with incompatible layouts (this is for free from the above fixes). Fixes#2726
XKB has various options for using keys to switch the keyboard layout.
When these are set, XKB will return keysyms which are unknown to GLFW,
so kitty will fallback to using a keymap without the options set, which
causes the keys to be interpreted as the original keysyms.
However, when these options are set, kitty shouldn't interpret the keys.
Therefore, check for some specific keysyms and return before translating
to GLFW keysyms.
There may be more keysyms which should be ignored, but as far as I can
see from https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/xkeyboard-config-2.29/symbols/group
these are the ones which can be triggered by XKB options.
Fixes#2519