Suggested refactorings to EditCommand and sub-functionality in anticipation of Helix Mode

[schlich]

In anticipation of #960 I'm opening this issue to brainstorm/track some thoughts on refactoring opportunities I've noticed should help simultanously with project maintenance and cleaner incorporation of text editing paradigms outside of traditional emacs and vi modes.

Aim

These are proposed refactorings that would help support Helix mode, while also improving the maintainability of the existing Emacs and Vi implementations. The goal is to reduce bespoke mode-specific patterns where possible and move Reedline toward clearer, more consistent abstractions that align better with established editor architectures.

In particular, these changes are intended to serve as a migration bridge from Reedline's current architecture toward patterns used by specialized editing libraries and projects such as modalkit, Helix, and Vim. Even if a larger architectural shift does not happen immediately, these refactorings should still improve the clarity and structure of the codebase on their own.

Approach

Roughly in order of importance, I think the following sub-tasks would help:

• Introduce dedicated modal state at the dispatch boundary

  The current Vi path needs mode information early in input processing to decide how an event should be interpreted, so that state should not be recovered indirectly from PromptEditMode. A good first step is to replace stringly mode changes with a dedicated enum, and then grow that into a HelixMode struct that owns the state needed for dispatch.

  This also moves Reedline closer to an architecture where modal state sits at the input boundary and drives interpretation directly, which is more compatible with eventually plugging in a ModalMachine from modalkit.

• Separate editor mode state from prompt/render state

  Prompt-related concerns should sit downstream of editing state, not define it. Add explicit conversions from HelixMode into prompt and cursor presentation so that the rendering layer reflects editor state rather than carrying editor behavior semantics itself.

• Move selection semantics into modal policy

  Inclusive vs exclusive selection, anchor direction, and visual/select semantics should be expressed as policy derived from modal state rather than being embedded in Editor hot paths. This keeps the editing core focused on mutation and makes mode-specific behavior easier to test, reason about, and replace.

• Split command execution into focused handlers

  Break the large edit-command dispatcher into smaller handlers for movement, selection, clipboard, text objects, and undo/redo. This would leave a thinner top-level integration point where modal state determines intent and the executor applies the resulting operations.

• Add EditCommand metadata helpers as a single source of truth

  Centralize command classification, display labels, and related metadata so that adding a new EditCommand does not require touching several unrelated match blocks. This becomes more important as modal dispatch starts producing a broader and more structured set of command sequences.