Refactor: Extract selection into a new ROUTINE (CodeRush-inspired)

[msarson]

Select a block of statements in a procedure's CODE (or a method / routine body) and extract them into a new ROUTINE, replacing the selection with a DO NewRoutine. Sibling of #280 — reuses its routine-placement + scope machinery.

Behaviour

  ! selected lines
  IF x
    A
  END

→ selection replaced with DO NewRoutine, and appended at the end of the enclosing procedure:

NewRoutine ROUTINE
  IF x
    A
  END

Extract with a placeholder name and immediately trigger rename-in-place on the new label (no modal prompt — user types the name once; DO + ROUTINE update together).

Why it's cheaper than extract-method elsewhere

Clarion routines share the procedure's locals and have no parameters or return type — so there is NO variable/parameter analysis (nothing to pass in, nothing to return). This is the big simplifier; it makes the feature closer to #280 than to #271.

Correctness constraints

1. Structurally balanced selection. The selection must not split a structure. Checkable directly from DocumentStructure (finishesAt): every structure that opens in the selected range must also close in it, and no closer in the range may belong to a structure opened before it. A depth-walk over existing tokens — no fragile text re-parse of END/period/single-line-IF. If unbalanced → don't offer.
2. DO calls stay in scope — solved by placement. Placing the new routine in the SAME enclosing procedure means any DO OtherRoutine inside the selection, which resolved from the original spot, still resolves from the new routine (same procedure scope). For a selection inside a local derived method, inherit Code action: Generate ROUTINE skeleton from an unresolved DO (lightweight sibling of #271) #280's method-vs-procedure placement choice.

Sharp edges (guard in MVP)

• RETURN / EXIT in the selection — EXIT from a routine returns from the routine; from main code it returns from the procedure. Extracting silently changes control flow.
• CYCLE / BREAK bound to a LOOP outside the selection — a balanced selection can still carry a CYCLE/BREAK targeting an enclosing loop that stays behind → invalid after extraction.

Open design question: when the selection contains such control-flow statements, should the MVP refuse (don't offer the action) or warn and proceed? (Leaning refuse for a safe first cut.)

Notes

Likely server-side (balanced-block validation wants the tokenizer/DocumentStructure), reusing GenerateRoutineCodeActionProvider's placement + ScopeResolver scope logic. Relates to #280, #271. CodeRush "Extract Method"-style.