Eventually register a terminfo with ncurses upstream

[fpqc]

Thomas Dickey, the maintainer of the ncurses project, also maintains the terminfo-db distributed with most Linux distributions. At the moment, the main TERM environment variable is xterm-256color, but not all xterm features are supported or even planned. When 1.0 releases, it would be good to leave xterm-256color as the default TERM environment, but also to maintain a separate terminfo with the ncurses project upstream. This means that as the changes in ncurses propagate down to the distros, the team can make a switchover and report the TERM as ms-terminal.

This will give the team the freedom in the long-term to add new features not implemented in xterm (for example, to support 32-bit color (i.e. an alpha channel)) or any other cool features they might dream up. Some projects like libvte and kitty have or previously had a bad relationship with the ncurses maintainer because they refused to submit their own accurate TERMINFO to the database.

[DHowett-MSFT]

Related: #1040

We've actually been in touch with Thomas about the existing ms-terminal termcap, which is derived from some amalgamation of Windows Terminal and conhost's capabilities. For a while, too, we've been talking about whether we should ship one with Windows as well.
It's slightly more complicated because both Windows Terminal and conhost have different capabilities. The latter is more robust, but eventually they'll line up (right now, WT is weaker because it has conhost translating for it.)

[fpqc]

@DHowett I actually have a question about that: Are you eventually planning on having WT do its own VT processing/rendering via a raw pty (but still using the shared renderer library) instead of having conhost do it? This would make things a lot easier to divvy up by profile, in particular this feature #2946

[DHowett-MSFT]

For that one, you'll want to track #1173. It's our (rough, mostly "we should do this") plan to converge the output engines for WT and conhost at some point.

For #2946, it's probably sufficient to parse but fail (ignore) OSC 52 when the console host is in VtIo mode, which will get conhost out of the way and give WT full control over what it does with the sequence.

[fpqc]

Very good! That was one solution I had already considered, but I wasn't sure if the maintainers would be happy with it.