rewrite keymap system, introduce transient-like functionality

[mahmoodsh36]

this is very preliminary work. this is an opinionated rewrite of the keymap system that i think makes more sense and is more intuitive.
yet to be handled/written/re-written:

• undefine-key
• priorities (some stuff is broken)
• proper transient-like functionality with proper grid displays and self-documenting keybindings
  the keymap system now allows for "dynamic" (non-static) keys or keymaps to be bound on-demand. unlike the old implementation which had nested pre-defined hashmaps, the new implementation uses a different data structure but tries to maintain backwards compatibility with the old implementation (atleast for now).
  i will be following this PR with more work and documentation/explanations. the goal was to rewrite the keymap system so that things like transient or which-key are a natural consequence of the data structure and are more intertwined with the core (unlike in emacs).

[mahmoodsh36]

an initial preview of the popup thingy. the double instances of unnamed keymap thing is intentional since its displaying nested keymaps.

[mahmoodsh36]

there are still things to be done such as:

• implement "sticky" keys such as infixes
• fix keymap priorities/precedence
• implement undefine-key
• some key sequences should be considered as a single prefix, such as keys "-g" that resemble commandline arguments and are composed of 2 keys not only one. this is currently not possible because a popup only displays single keys and doesnt recurse to display the longer key sequence which is the intended design, but maybe we should also allow for some sub-keymaps to be recursed into and longer key sequences to be displayed.
• functionality isnt yet customizable beside the CLOS interface. more customization variables should be introduced that customize behavior.

[mahmoodsh36]

i need to stop the habit of force pushing, lol

[mahmoodsh36]

i introduced the following "suffix" values for now:

• :cancel to drop the current key sequence entirely without invoking a command
• :drop to avoid adding the current key to the key sequence, which makes the prefix act as an "infix" key
• :back to avoid adding the current key and to pop the last recorded key which has the effect of "going back" to parent menu in the transient popup.

this behavior is customized by setting the value of the suffix to one of those (or to a symbol that is resolved later to a command that is executed). i dont think this belongs in the suffix slot, i think it would be more ideal for a suffix to always resolve to a command, but currently the function 'read-command' which is part of the event/key handler can only resolve a specific key sequence to a single command. currently the behavior of an infix (such as 'choice') is customized by overriding 'prefix-invoke' but this functionality i think belongs in the suffix itself. i have yet to think of a redesign to make this more intuitive.

i think the suffix itself shouldnt necessarily hold the special value that decides the behaviors cancel/drop/back, i think that belongs in a different defmethod (call it prefix-behavior) so that a prefix can both resolve to a command and have custom behavior.

[mahmoodsh36]

there are still things to be done such as:

• implement "sticky" keys such as infixes
• fix keymap priorities/precedence
• implement undefine-key
• some key sequences should be considered as a single prefix, such as keys "-g" that resemble commandline arguments and are composed of 2 keys not only one. this is currently not possible because a popup only displays single keys and doesnt recurse to display the longer key sequence which is the intended design, but maybe we should also allow for some sub-keymaps to be recursed into and longer key sequences to be displayed.
• functionality isnt yet customizable beside the CLOS interface. more customization variables should be introduced that customize behavior.

first 3 are done.

[mahmoodsh36]

this is a screenshot of the popup shown by invoking the demo keymap defined in demo.lisp, it supports things like multi-key prefixes, nested menus, and different types of infixes/prefixes (implemented through CLOS by inheriting from prefix).

[mahmoodsh36]

whats left to be done:

• turn lambda suffixes into commands. together with rewriting the event/key-reading loop to make help keys work properly. (currently running help-key on a key sequence that is bound to a lambda doesnt function like you'd expect).
• introduce deprecation warnings (some things were renamed and i should try not to completely break compatibility).
• implement more types of prefixes.

currently, the keymap structure uses different concepts of a 'hierarchy' for different use cases, such as a hierarchy for keymap precedence, another for keymap inheritance, and another for keymap prefixing. the 3rd is naturally distinct but the first 2 have some form of relation and im thinking of a way to unify them (and possibly turning keymaps into types instead of just instances).

i think this is about it. this functionality is already usable even at this stage.

[mahmoodsh36]

main thing thats left is to rewrite the event loop to make things more "natural". currently suffixes can be lambdas but they should be commands instead. to fix this i'd want the event reading loop rewritten.
but the code is already usable as-is, this one thing aside.
deprecation warnings instead hard renames/rewrites would be nice too.