Have `expandAlias` emit `TextEdit`s like the rename handler instead of a custom request

[andyleejordan]

Follow-on from @JustinGrote's review on #2312: #2312 (review)

Yeah looks fine to me. As a follow-on issue we should probably update the rename handler to use this same code path if it isn't already.

The rename handler (RenameService) is already on the modern path — it uses System.Management.Automation.Language.Parser.ParseInput plus AST visitors and never used the legacy PsParser, so there's nothing to migrate there. #2312 brought ExpandAliasHandler onto the same modern parser.

The remaining divergence is in output shape, and the reusable direction is the reverse of "rename adopts expand-alias": expand-alias should adopt rename's edit model.

• ExpandAliasHandler resolves aliases, then returns a single wholesale-rewritten string over the custom powerShell/expandAlias JSON-RPC request.
• RenameService walks AST extents and returns TextEdit[] over standard textDocument/rename, using ScriptExtentAdapter to map PowerShell 1-based extents to LSP 0-based ranges.

This is also what #2108 itself anticipated: "return a proper edit (potentially deprecating the need for an entirely separate custom request)."

Proposed work:

• Rework alias expansion to emit TextEdits (reusing ScriptExtentAdapter) covering each command-name token's extent, instead of returning a rewritten document.
• Investigate folding it into a standard LSP surface (e.g. a code action) and deprecating the custom powerShell/expandAlias request + its client plumbing in vscode-powershell.

Note this changes the client contract, so it needs coordination with the extension — which is why #2312 was scoped to just the parser swap.

Drafted by Copilot (Claude Opus 4.8).

[JustinGrote]

@andyleejordan I guess I'm smarter than I thought. I do like the idea of converting this to an LSP codeAction rather than a custom handler.