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

[schlich]

In anticipation of #960 I would like to suggest refactorings in the aim of making upcoming changes smaller and easier to maintain:

1. Introduce EditCommand metadata helpers

   • Add a single source of truth for command classification (MoveCursor, EditText, NoOp, etc.) and command display labels.
   • Replace duplicated match logic currently spread across formatting and behavior classification.

2. Extract selection semantics from Editor

   • Move inclusive/exclusive/anchor-direction rules into a dedicated selection policy component.
   • Keep Editor focused on mutation orchestration; avoid mode-specific selection rules in hot paths.

3. Split command execution by concern

   • Break the large run_edit_command dispatch into smaller handlers (movement, selection, clipboard, text objects, undo/redo).
   • Keep the top-level dispatcher thin and easier to diff when adding new commands.

4. Unify cut/copy range operations

   • Consolidate repeated cut_* / copy_* patterns around shared range builders + one mutation primitive.
   • Remove duplicated clipboard/newline handling and align linewise behavior in one place.

5. Separate mode state from prompt rendering state

   • Introduce an internal editor-mode abstraction with explicit conversions to prompt/cursor presentation.
   • Prevent prompt-mode enums from carrying editor behavior semantics directly.

Acceptance criteria

• Adding a new EditCommand no longer requires touching 4+ separate match blocks.
• Selection behavior rules are tested through a dedicated policy unit with mode-specific fixtures.
• Editor command dispatch is split into focused, testable sub-handlers.
• Existing tests pass with no regressions in Vi/Emacs behavior.
• Follow-up Helix PRs can be smaller and more localized.

I would like to make separate sub-goals/PRS for various aspects of these changes but this issue can serve as an overall sounding board for the refactoring work as a whole.