Description of the new feature/enhancement

I've been working for a while now on a refactoring the ConhostInternalGetSet code (as a follow up to PR #12247), trying to move as much as possible into the AdaptDispatch class, and condensing the ConGetSet interface down to a minimal set of operations.

The idea is that the the AdaptDispatch class could then be used in Windows Terminal in place of the existing TerminalDispatch (i.e. issue #3849), and only have a handful of methods in the ConGetSet interface needing terminal-specific implementations.

I'm not done yet, but I'm far enough along that I'm satisfied that this is the right approach, and I wanted to let others know my plans, and check whether you're happy with what I'm doing.

Proposed technical implementation details (optional)

The general idea is that we provide the means for AdaptDispatch to access the high-level structures that are common to both conhost and terminal (like the Renderer and the TextBuffer), and then a lot of the operations like EraseAll, InsertLines, and ScrollRegion can be implemented entirely in AdaptDispatch, avoiding the need to implement them twice.

In some cases, the structures we need are static, and can be passed through to AdaptDispatch in the constructor (e.g. the Renderer, RenderSettings, and TerminalInput). Others are dynamic, but can easily be retrieve via new methods in the ConGetSet interface (e.g. the active TextBuffer, and the active virtual viewport).

Taking this approach, I've so far been able to eliminate 31 methods from the ConGetSet interface (adding only 4 new ones), and I think there are still more that could be nuked eventually.

My current plan was to submit this as two PRs: the first covering the refactoring of ConhostInternalGetSet, and the second dealing with the reuse of Adaptdispatch in the terminal (I haven't looked at that in much detail yet, so it might be more complicated than I imagine). Even just the first bit is quite a large change, though, so maybe you'd prefer it split up even more?