Hydra was useful to prototype Rigpa modes, but we need more lifecycle
hooks in order to ensure clean mode entry and exit. There were a
number of hacks in Chimera (the modal interface abstraction layer that
was introduced specifically to abstract such hacks and present a
simple modal API) to achieve an approximation of the expected behavior
with mode transitions, but there were still some corner cases that
could not be addressed.

With Lithium, we use Emacs's built-in minor modes to implement the
more rigid Vim-style (and yet, "point-free," Symex-style) modes we're
looking for. This allows us to benefit from all of the existing
infrastructure available for minor modes, and keeps the overlying
additions "lightweight." By having an in-house, dedicated, modal
interface framework, we also gain the flexibility to add the lifecycle
hooks we need and tailor the implementation, without having to work
around design choices that may have been made for requirements
different from our own.

Mention including Lithium config as well since that package isn't on
MELPA (or another package archive) either, and (as I understand it)
cannot be declared as a dependency using `Package-Requires`.

As a convention, we'll avoid specifying anything beyond keybindings in
the mode definition, leaving everything else to happen via state
lifecycle hooks.

This runs exit hooks for the previous mode and entry hooks for the new
mode. We also don't run any hooks for Lithium modes which do all their
hooks internally and via their exposed API. We currently use
`manage-hooks` as a proxy for "is this a Lithium mode?" Just a
temporary bridge to something more explicit.

This streamlines these actions so they're taken at the appropriate
points in the mode transition lifecycle. Currently, some of these are
no longer functioning correctly (e.g. keybindings no longer active in
Symex state, #9), but we'll hopefully restore their functioning in a
proper way as we go.

Rather than post-exit hook, as the latter is only called in the high
level switch mode function and not the low level mode transitions used
in enter-appropriate-mode.

Retain transparency menu in Hydra

We now use Lithium for global modes as it provides the lifecycle hooks
we need to be able to cleanly treat it as a modal interface provider.

We still use Hydra for features where a menu-driven interface is
desired and not formally a modal one.

Also disable Evil Normal state in these modes as that would otherwise
take precedence over the Lithium mode bindings.

For global modes, we need to do this to ensure that the mode reflects
correctly in all buffers via the Evil state indicator, and all that
these evil states don't take keybinding precedence over the active
global Lithium mode.

This avoids encountering a `nil' evil state in some post-exit
actions that were being performed "for all buffers" (as I recall).

We recently fixed an infinite recursion where post-exit hooks enter
the "appropriate" mode which calls the main "switch mode" interface,
which itself attempts to exit the current mode before entering the
next, and thus triggers post-exit hooks again. To address that, we had
the "appropriate" mode entry function call the low-level entry
function instead of the main switch mode transition function, but this
meant that these were no longer triggering the pre-entry hooks as part
of mode entry.

This moves the pre-entry and post-exit hooks into the low-level entry
and exit functions, respectively, so that they are correctly triggered
in either of these cases (while still avoiding the original infinite
loop since we only _enter_ and do not _exit_ (again) as part of
post-exit hooks, while still doing both in the high level "switch").

We also need to explicitly call low level mode exit in on-demand mode
transitions like "enter lower" and "escape higher" when in a non-local
starting mode.

The built-in predicate for whether a buffer position is visible on
screen returns true if we pass in a null buffer position, which is not
what we expect here.

Instead of using Evil. For the kind of simple
point-free ("Rumpelstiltskin") modal interfaces used in Rigpa, Evil is
more than we need.

We don't need anything in pre-entry currently since it isn't
evil-based anymore.

The line highlight itself is the relevant cursor in line mode.

Avoid defining these separately for each mode within Rigpa.

Don't rely on name-matching interning magic.

Checks if there is a lithium mode active, and otherwise uses evil
state.

Now that Lithium supports mode "stacks," in some cases (i.e. native →
foreign transition), we want the native mode to be preserved and the
new one just pushed onto the mode stack. So in such cases, we do not
exit the source mode before entering the target.

Don't attempt to enter any other mode, as with the mode stack, there
should already be an active mode once the foreign mode has been
exited (popped).

We no longer rely on the evil state as the source of truth on what the
current mode is (except for evil-backed states, which currently are
just the built-in evil states). But we do still rely on evil for UI
feedback, to indicate visually which mode we are in, even for modes
that are not evil-backed. We do this just because there is existing
infrastructure for this for Evil, in the form of mode line
enhancements and perhaps other things. Eventually we will likely want
to move away from this, but for now, the only thing we still need to
do upon exiting forreign modes is to enter the appropriate evil state
for UI feedback purposes, which we do now instead of attempting to
enter any particular local mode (which we don't need to do since there
would still be a local mode on the stack upon foreign mode exit).

We no longer want to rely on evil as the source of truth for the
"current mode."

Support symex implemented as a lithium mode

This still ends up setting the evil state in the original buffer rather
than the timemachine buffer, though the evil state is set post-entry.
Not sure why.

Note the evil state is purely for UI feedback purposes and has no
functional effect.

This is a general step towards maintaining a distinct notion of a
current mode within Rigpa, which may use the current mode reported by
Evil or Lithium as part of its operation.

But it also is in response to a bug where [u]ndo'ing while in Symex
mode causes the level to be reconciled to the level of Normal in the
current tower (e.g. 2), even though we remain in Symex state. This
seems to happen because as of emacs-evil/evil#1888, undoing explicitly
goes into Normal state first, and then returns to whatever the
original state was. In Rigpa, Normal is backed by Evil but Symex is
backed by Lithium, even though it sets the Evil state for UI feedback
purposes. As a result, we only watch the Evil state transition to
reconcile the level when entering Normal state, but not Symex state,
since we do not expect the Evil state transition to be the way in
which Symex state is entered (it's rather just an effect of Symex mode
entry via Lithium). As a result, during the undo operation, we see the
transition to Normal and reconcile the level to 2, but do not see the
transition back to (evil) Symex state, and thus do not reconcile the
level back again to 1.

This fix alleviates the bug because even though
`rigpa--reconcile-level` is still only called upon Normal state entry,
it does not result in the level actually changing because Rigpa's
determination of current mode now first checks whether a Lithium mode
is active, before checking the evil state. So even though the latter
has changed during the undo operation, the mode remains the same as
before, as the former has not changed.

While in replace state, escaping was having no effect. As it is
considered a foreign state, it attempts to only exit the mode, which
for evil-backed modes is a no-op. Additionally, as it isn't a lithium
mode, there isn't even a notion of a stack wherein exiting replace
mode would reinstate any prior mode. Escaping to normal seems the most
straightforward thing to do, but I'm not sure if there may be a more
correct handling.

Formerly I think with hydra we were implicitly exiting. With lithium,
global modes like Buffer remain active even when the original buffer
is killed, so we need to explicitly exit at the appropriate time.