Persistent modes

[jmacdonald]

As of today, Amp tracks its current/active mode using a single enum field on the Application type. When the active mode is changed, the old mode is discarded and a new one is constructed. A side effect of this is that the active mode's state is lost during the transition. There are situations where persisting and recalling state across modes is beneficial:

• when searching/replacing text, preserving the search query so you can quickly find the next match after making edits
• when selecting a range of text in Select/SelectLine modes, temporarily switching to jump mode to select the end of the range
• pinning search tokens in open mode to narrow down results to your area of focus when working in larger projects

The first two behaviors above exist today, but as you'll see in the diff below, they're implemented by explicitly storing required state in their relevant modes or the Application type itself. This has helped minimize and isolate the complexity involved with persistent state, but as we look to implement more features that require it, the pattern justifies building a generalized system that handles this for all use cases.

That generalized system is the focus of this PR. As you'll see below, we now build all application modes up front, store them in a hash map, and recall them when switching modes. To do so, I needed to introduce the following notable changes:

• build all modes when initializing the Application type to hydrate the map
• add a new ModeKey type as a stateless enum key into the map
• add a reset method to modes where a clean slate is expected (e.g. rebuilding open mode's project directory index)

Once this lands, we'll be able to leverage these persistent modes to build some neat features that should really help improve the ergonomics of Amp. 😎