Adopt VT extension "Unscrolling the screen" from Kitty

[WSLUser]

Description of the new feature/enhancement

Kitty has recently shipped an awesome VT extension to the SD (Pan up) escape code from the VT-420 terminal to tackle the issues with text being lost under the cursor. I'd like to see this added in Windows Terminal as well. See https://sw.kovidgoyal.net/kitty/protocol-extensions.html#unscrolling-the-screen. As there have been several issues raised in the past surrounding this issue, this appears to be the perfect solution to prevent further issues from being raised about it. Also, since Windows Terminal adopted private extensions from ConEmu to address other issues, I see no reason why we can't also adopt some of Kitty's protocol extensions as well.

Proposed technical implementation details (optional)

[WSLUser]

@j4james and @skyline75489 since I know this is your thing.

[DHowett]

Interesting. For conhost this would be possible (unless the lines were pushed up off the top), but for Terminal it would not. Due to ConPTY maintaining its own buffer which crucially does not have a scrollback, it wouldn't be able to tell Terminal what to put back on the screen.

[WSLUser]

So for Terminal, we'd need to wait for the ConPTY Passthrough Mode to become available.

[j4james]

I actually mentioned this before in issue #9622. I thought it might be a nice way to provide VT applications with equivalent functionality to existing console APIs, and also allow us to forward those console APIs over conpty. But as @DHowett mentioned, it's not currently feasible with the existing conpty implementation (at least I couldn't figure out a way to make it work).

Also, while I'm in favour of an extended scrolling sequence in general, I'm vehemently opposed to the Kitty implementation. The escape sequence that was chosen is pointlessly using a reserved codepoint, and would be much more appropriate as a private parameter prefix on the existing scrolling ops. Then there is an arbitrary limit on how much you can scroll back, which makes it useless for anything other his one use case. I also didn't think switching from a viewport pan to a buffer scroll when it reached the boundary was a good idea, and would limit some of the things that could be achieved with it.

I did raise all of these points when the subject was discussed in terminal-wg, but you can image how well that feedback was received. So if we do ever get around to doing something like this, I think it's almost certain we're going to need to do our own thing (although ideally in agreement with other conpty terminals that could benefit from the extra legacy app support that these sequences could provide).

[christianparpart]

There is actually a critical design flaw in Kitty's proposal. This modified SD would be incompatible to horizontal as well as vertical margins, which are otherwise we'll defined. Or: how do you fill up the top created lines in such cases?

[zadjii-msft]

Yea, I agree, I kinda hate this idea. I trust pretty completely j4james and christianparpart on this subject.

I'll leave this open in the freezer as "maybe this is a valid idea, if someone can actually come up with a sensible implementation", but not as "do the kitty thing".