Consider using ASCII printable characters in the fancy TUI

This is a spin-off of #8994.

@Alizter @rgrinberg The current character choice for the TUI has several issues that could hurt portability. My concrete suggestion is to stick with ASCII printable characters for maximum portability and the potential to cut down the vendoring. Also, an ASCII Art can still look great with good colors. I totally understand the desire to use fancy Unicode characters. Let me explain in detail why ASCII printable characters are still the best choice.

1. Visual widths are not defined. There's actually no official standard about how "wide" a Unicode character (or Unicode sequence) should be, even in a terminal. The actual width can depend on the terminal (emulator), the font(s), and even the locale in some cases, and there's no reliable way to detect it. The most reliable assumption that will work in 99.999% cases is that all characters whose East Asian width is either "Halfwidth" or "Narrow" occupy exactly one "cell" in a terminal. Note that this class includes all ASCII printable characters. In some real implementation a box-drawing character could potentially occupy two cells, but I don't want to go into the details here unless someone's interested. Just know that these characters can have unexpected visual widths in a real terminal (emulator).

2. Font availability. A modern system that uses UTF-8 might still lack a consistent set of fonts that cover the whole Unicode range. Or maybe the user does not configure the fonts correctly. An unsupported glyph can be shown as a replacement symbol, ruining the Unicode Art. In comparison, one can almost always expect that ASCII printable characters will work. As a bonus, a terminal font designed for programming is usually heavily optimized for these ASCII characters, maybe with lots of ligatures. In short, they will look consistently good on all platforms.

3. Potential to cut down the vendoring. By avoiding Unicode, there's a chance that one can cut down the vendored notty (e.g., its Unicode segmentation algorithm and the heuristics to "guess" the width, etc.). However, I think the portability is already a strong argument and I prefer not to elaborate on how to dramatically shrink the notty library unless someone wants to maintain the cut-down version.

4. Bonus: even ISO/IEC 8859-1 is okay. In some (rare?) cases, maybe the system is still using some non-Unicode legacy encoding. ASCII printable characters will survive even those cases. I'm saying this because the OCaml has not officially abandoned the support of ISO/IEC 8859-1, which might indicate that someone's terminal is still not using UTF-8 (though I wonder why).

I am happy to elaborate on any of the above points.

Some technical details: by "Unicode characters" I meant "Unicode scalar values", and by "Unicode sequences" I mostly meant "Unicode (default, extended) grapheme clusters". I decided not to use these official terms that could make the discussion more difficult to understand.

Start by reading the related issue #8994 and locating the fancy TUI character choices. Determine the scope of replacing them with ASCII printable characters, then verify that the resulting presentation remains usable across terminals and that any vendored notty dependencies affected by the change are understood.