Add support for the S8C1T/S7C1T escape sequences

[j4james]

Description of the new feature/enhancement

The S8C1T and S7C1T commands enable an application to choose whether the terminal should use C1 controls when sending key sequences and query responses. For example, instead of encoding a CSI prefix as ESC [, the terminal would use a single CSI codepoint (i.e. U+009B).

Back in the days of the 8-bit hardware terminals, this had the advantage of being slightly more efficient (your sequence introducers would take 1 byte rather than 2). And another bonus was that it made it easy to distinguish an Esc key (assuming your keyboard had one) from other key sequences that merely started with the ESC character.

However, these days you're more likely to be using a UTF-8 encoding, in which case a C1 control character is still going to occupy two bytes, so there is no advantage in terms of sequence length. And the ability to distinguish an Esc key from other key sequences is somewhat diminished by the modern usage of ESC as a prefix for Alt key combinations.

In short, there's probably not much demand for this functionality outside of people wanting to connect to legacy systems, but it would be nice to have just for completeness sake (it's a requirement for VT level 2 conformance).

Proposed technical implementation details (optional)

Some of the framework for the key sequence encoding was already added in PR #16511, so that just needs to be hooked up to a new input mode which can be toggled by the S8C1T and S7C1T escape sequences. We need to do something similar in AdaptDispatch for all the query responses, but that's also fairly straightforward.

However, if we want to support 8-bit C1 sequences, as used in legacy systems, we also need a way to switch the input code page from UTF-8 to something that can cleanly pass through 8-bit bytes (like ISO-8859-1). Fortunately we already have a DOCS escape sequence which sets the output code page to ISO-8859-1, and I think it's reasonable to extend that to set the input code page at the same time.

The catch is that this won't work in a WSL shell, because WSL doesn't pay any attention to the input code page. And while it is potentially usable from a Windows shell, the typical use case will involve connecting to a remote system, which means you're going to ned a ssh or telnet client that is 8-bit capable (and I think that rules out the Windows inbox clients).

The bottom line is there are a few hoops you need to jump through to get this to work. Given these limitations, is it still worth adding?

[lhecker]

Given these limitations, is it still worth adding?

Personally, I'd add it if there's need for it or if it enables new use-cases. But I'm also fine with this:

[...] but it would be nice to have just for completeness sake (it's a requirement for VT level 2 conformance).

[DHowett]

I am A-OK with "completeness sake", even if there are limitations and some minor hoops for applications to jump through.