Fix garbled UCM prompt on Windows

[jesselooney]

Overview

Fixes #3275

On Windows, the UCM prompt is corrected from this
[0m[32m.[0m> [0m
to this
.>
but there is still no color.

Implementation

This change appends the ASCII start-of-text (\STX) character within the toANSI and resetANSI functions inside the Unison.Util.ColorText.toANSI function, which should mean that every ANSI escape sequence rendered with that function should be followed immediately by this character. This is the recommended practice for haskeline, and most importantly should prevent the remainders of character control codes seen in issue #3275 from being displayed when haskeline removes the leading \ESC character on Windows. This does not fix the lack of coloration of the UCM prompt on Windows, but it does stop the prompt from appearing garbled.

While \STX is a control character and should not be rendered, I could see not wanting to insert them in every single place toANSI is used and instead just limiting this change to affect haskeline prompts. I didn't do that because it would require more work and the PR as it stands might be fine, but it could definitely be done.

Additional notes

The issue of haskeline removing color codes on Windows is seemingly out of our control. See haskell/haskeline#130 for more information on the topic.

---

This change is 

[ceedubs]

Thank you @jesselooney!

I don't have a Windows machine to test this on, but I can confirm that on my Debian machine this fixed an annoying issue that I believe had to do with the text width calculation.

Before this PR, if I ran .temp> compile main.nodeMain nodeMain then it would work fine but after I hit enter it would appear like this in my terminal:

.temp> compile main.nodeMain nodeMain       Main nodeMain

After this PR it looks like one would expect:

.temp> compile main.nodeMain nodeMain

I could see wanting to restrict this change to the prompt, but I also don't know the implications of not doing that. I'll leave that judgement for someone more familiar with haskeline and the UCM CLI.

[ChrisPenner]

Great! Thanks for this! Really helpful to know that someone has tested this on Windows 👍🏼

[aryairani]

Thanks @jesselooney!

[aryairani]

Here's what I'm seeing with the patch:

The prompt looks good (though it doesn't include color anymore, as we'd expect), but every other escape code is a bit messed up.

Does this not happen for you, @jesselooney? Could you send a screenshot?

[jesselooney]

I see none of that.

That was from the VS Code terminal, and I also tested from Windows Terminal and plain old Command Prompt (shown below in that order).

Command Prompt struggles with emoji and the colors are weird, but no issues that look like your screenshot. It's very strange that those escapes don't show at all for me.

I do notice that my UCM prompt version reads latest-211-gf5ecc899b whereas yours reads dev/M4-329-g3d9a2321d. Not sure what's up with that; I pulled and built from trunk just now, but maybe I'm missing something.

In any case, I think there's still a simple fix: rename ColorText.toANSI to something else, say toANSIWithSTX, and use this function when converting ColorText for the haskeline prompt. Then create a new function toANSI which simply calls toANSIWithSTX and filters out all occurences of \STX, preserving the old functionality (and name) while preventing code duplication. Of course, there is a slight functionality difference in that \STX characters can no longer be displayed, but that seems like a non-issue. How does that sound?