Change input handling strategy

[aadcg]

A keyboard event may be interpreted as (1) a physical location or (2) as the returned value given the state of the shift modifier and OS keyboard layouts. In the language of web browser specifications, this corresponds to KeyboardEvent.code and KeyboardEvent.key.

WebKitGTK and Electron, naturally, provide APIs to access both. Historically, we have relied on (2), while we kind of support (1) in a shady way.

As per #3547, relying on (2) on macOS isn't wise since the Option key (Alt or keymaps:+meta+) triggers a layer. For instance, as per (2), M-s would need to be specified as M-ß.

In short, (2) is stateful and not portable.

What do we gain if we choose (1)? People using alternative keyboard layouts can still use their keybindings without extra ad-hoc manipulations. As of today, it is possible to bind keys as per (1) in a cryptic and unportable way (e.g. C-#30 as to mean C-a, but note that the correspondence between keycode 30 and a is only valid on GNU/Linux).

Among the consequences of adopting (1): commands can't be bound to keys that depend on OS keyboard layout (e.g. C-ф). Note that all keyboard layout introduce new characters and that is a rather jarring case. E.g. take QWERTZ and note that binding C-y requires hitting the key that prints the character z, not y. The issue vanishes if the user sets QWERTZ on the keyboard firmware level instead of relying on the OS.

In short, we should take (1) and replace nkeymaps by a new library.

[aadcg]

keyspecs-without-keycode and keyspecs-with-keycode become obsolete in the new implementation.