API alterations to allow injection of hotkey parsing and event processing

I think a useful migration strategy would be to allow serialization/comparison to be overridden as part of the API.

When we talk about what this library does that is "novel" (as in, something you cannot _reasonably achieve_ in a few LOC locally) the library does three things:

- It manages many shortcuts by implementing a Radix Trie.
- It manages event listening & dispatch avoiding footguns: for example delegated events, ensuring hotkeys aren't fired on form fields, etc.
- It provides the above with a simple `install`/`uninstall` API to simplify adding/removing event listeners and state from the Radix Trie.
- It comes up with some lose specification of how to expand/compare hotkey strings to decide when to fire a hotkey combo.

The last one is what causes us a lot of trouble and causes some trashing in this library. `radix-trie.ts` hasn't been touched in 9 months, prior to that 2 years ago. I'd say `radix-trie` is "feature complete". Meanwhile `hotkey.ts` has a regular cadence of alterations every few months as we reach edge cases and scale our use of this library.

The chief problems with the serialization format are:

- It is a psuedo specification. There's no formal set of possible values or a well defined grammar or spec. It is an ad-hoc grammar using RegExps. While this works fine for the most part, it is a source of bugs and confusion, as well as differences of opinion.
- It doesn't properly encode all of the state about what we as developers _intend_ shortcuts to be. We've discussed this quite a lot synchronously; the concept of "logical" (`WSAD`) vs "Semiotic" (`?`) shortcuts.

Effectively the serialization of these shortcuts is, what you might call, unsolved. So I say let's make that apparent by allowing it to be overridden in the API.

The current API is as follows:

```typescript
export install(element: HTMLElement, hotkey?: string): void {}
export uninstall(element: HTMLElement): void {}
```

I propose we expand this to the following:

```typescript
export type ProcessHotkey = (hotkey: string): string[][]
export type ProcessEvent = (event: KeyboardEvent): string

export class HotkeyManager {
constructor(
processHotkey: ProcessHotkey = expandHotkeyToEdges,
processEvent: ProcessEvent = eventToHotkeyString
)

install(element: HTMLelement, hotkey?: string): void {}

uninstall(element: HTMLElement): void {}
}

const defaultManager = new HotkeyManager()
export const install = defaultManager.install
export const uninstall = defaultManager.uninstall
```

By making a class, we can define custom processing for shortcut keys which allows users to define their own shortcut models, but also allows us to make more breaking changes behind experimental APIs, and even feature flag them. By still exposing the `install`/`uninstall` functions per the existing API, we ensure backwards compatibility which minimizes breaking changes, and allows us to "make the hard change easy then make the easy change". A 2.0 change could effectively swap the default hotkey functions out for the newer API, as a one line change.

Thoughts @github/ui-frameworks?

Commencez par lire hotkey.ts et radix-trie.ts, puis comparez l’API actuelle d’install/uninstall avec les interfaces proposées HotkeyManager, ProcessHotkey et ProcessEvent. Déterminez comment intégrer la sérialisation personnalisée et le traitement des événements sans modifier les default exports existants ; le travail est considéré comme terminé lorsque la conception de l’API et le comportement de compatibilité sont convenus et implémentés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.