Fix color output for non-256 color terminals

[mislav]

The function enableVirtualTerminalProcessing must return an error if virtual terminal processing (only applicable on Windows) was not enabled, otherwise we assume that the terminal supports both 256-color and truecolor (since that is true of Windows terminals with virtual terminal processing enabled).

We have been erroneously assuming that all non-Windows terminals are 256-color and sending escape sequences to those that cannot interpret them. This led to some parts of Survey prompts being invisible on old terminals.

Regressed in #5681

[heaths]

Wouldn't this completely break alternate screen buffers on *nix then? There are other ways of detecting whether VT sequences are supported:

• Using tput e.g., https://unix.stackexchange.com/questions/450365/check-if-terminal-supports-24-bit-true-color
• Feature Request: Clients of terminal need a way to inquire about the capabilities of the terminal microsoft/terminal#1040 (comment)

EDIT: Yes, this would now print pages of information to *nix as it did before with Windows: https://github.com/cli/cli/pull/5681/files#diff-887a9d62c9cb63f7a0eab6a95bf42464d5bcc5ffb4df181dcb00748b9ac24da7R410

The original assumption was that Windows was late to the party for decent VT sequence support, but was otherwise prevalent in *nix terminals for many, many years. Were there particular terminals where this didn't work that we could test in? Relying on either tput (which some other modules - even some of mattn's - use) or sending a VT sequence and reading the result should be safe.

[heaths]

Thinking about this more, it was already assumed before with the old implementation that VT100 sequences were supported for --watch, so maybe a better fix overall is keep what you have but where it's used to decide if alt screen bufs are supported, do a check on windows && enableVirtualTerminalProcessing, or assume. It would be no worse than before since VT100 sequences were being used even to clear the screen and set the cursor position. It seems very unlikely given how long these VT sequences have been around that one set is supported but not another. @mislav @samcoe thoughts?

I could write up a PR, but would love to test out on whatever *nix terminals this failed to make sure. At the very least, it should be no worse than before.

[heaths]

Yes, the previous code before my change assumed VT support: https://github.com/cli/cli/pull/5681/files#diff-4ca7c158ba1609a9968f3f5bd80a5138fd242ed3b07882e12774ff0ac3188fcfL215-L223. I've got a PR incoming to effectively restore that assumption and separate logic from color support.