Addressing Unicode character width ambiguities in kitty

[unxed]

I would like to propose an improvement for kitty that addresses one more long-standing issue in terminal emulators: the ambiguity of Unicode character widths.

The problem lies in the lack of a definitive method to determine whether a specific set of Unicode code points should be treated as wide (full-width), regular (half-width), or non-printable character. The interpretation of these properties can vary between Unicode versions, and applications running in a terminal have no way to ascertain which Unicode standard the terminal adheres to. Even worse, different libraries produce inconsistent results: for instance, the system call wcwidth (which is notoriously unreliable on many systems) often yields results that differ from those of ICU. This inconsistency leads to issues in text editors, console-based file managers, and similar applications.

Various approaches have been proposed to address this issue. For example, iTerm2 introduces a special escape sequence that allows the terminal to adhere to a specific Unicode version:
https://iterm2.com/documentation-escape-codes.html#:~:text=Unicode%20Version
However, this method has its own drawbacks, such as the complexity of implementation in terminal emulators (e.g., how should the terminal handle all the differences between Unicode versions?). Additionally, discrepancies might still arise if the terminal and application use different libraries.

Another, seemingly more robust, solution has been proposed by the developers of VTM. Their idea involves using specific escape sequences to explicitly define how the terminal should render individual characters. Here's the specification:
https://github.com/directvt/vtm/blob/master/doc/character_geometry.md

It would be fantastic if you could look into this issue and consider addressing it when you have some time. Thank you!

[kovidgoyal]

dup of #8226