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.