Proposal: separate language support from vscode-R again

The issue names no implementation files or tests. Start by reviewing the existing language-server integration and related issues #1540 and #1648, then compare the proposed minimal extraction with the extension-pack structure. Done would be an agreed extraction approach with minimal behavior changes; the larger runtime split is explicitly separate.

I would like to reconsider separating the language-server integration from vscode-R, similar to the old vscode-r-lsp, and eventually make REditorSupport.r an extension pack / umbrella extension.

When vscode-r-lsp was merged into vscode-R in 2.1.0 (#695), languageserver was effectively the standard choice for R language intelligence.
That is no longer the case.

The R editor ecosystem now has several actively developed, independently distributed tools with VS Code extensions:

• Air provides a very fast Rust-based formatter and language server.
• Jarl provides a fast Rust-based linter with diagnostics and automatic fixes.
• Arity provides a full Rust-based language server with completion, hover, go-to-definition/references, rename, diagnostics, semantic tokens, and more.
• Posit's Oak may become another standalone R language server in the future.

In particular, these newer tools are designed around fast static analysis.

Given this ecosystem, it no longer seems ideal for vscode-R itself to own one particular LSP client/runtime combination.
VS Code ecosystems such as Python and Java also separate language support and other tooling into independently maintained extensions, often combined through an extension pack.

A possible long-term structure would be:

REditorSupport.r          # extension pack / main entry point
├─ REditorSupport.r-syntax
├─ REditorSupport.r-runtime
└─ REditorSupport.r-lsp   # current languageserver-based integration

r-lsp could remain the default language support installed by the pack, while users could disable or replace it with Air, Jarl, Arity, or future alternatives without fighting functionality bundled into the main extension.

The first step could simply be extracting the existing LSP client with minimal behavior changes.
A larger runtime split can be discussed separately.

Related to #1540, #1648