DRAFT: Expand zero-width support for ZWJ and emoji sequences

[jquast]

• Bugfix: wcswidth() for zero-width join characters such as used in emoji sequences, and variations such as emoji skin tone, as well as many other non-printable characters now correctly identified as zero-width.
• Enhancement: new function width(), a copy of wcswidth() without the POSIX compliance to return total width of -1 for any C0 or C1 control characters, those characters measured as width 0 by this new function.

Discussion,

• This implementation of ZJW for emojis does not qualify whether the sequence is supported !! This is possible because of the publication of "recommended" sequences in emoji-zwj-sequences.txt. I experimented with creating a large optimized regex of all supported emoji sequences as part of code generation, but I refrained from implementing it -- it seems like a large cost to lookup every possible sequence, even an optimized regex (using triregex library) is many tens of thousands of characters. Whereas this implementation increments idx past the next character, assuming they are cojoined is very high-performing and easy to implement
• It is possible to provide a EMOJI_ZWJ_VERSION environment variable, which when undefined is set accordingly to the same release of UNICODE_VERSION. This would require implementing "recommended sequence" checking for the given version level, and returning the length as assumed it would be rendered when supported, for example 2 wide co-joined vs. unsupported, 4-wide with two side-by-side.
• I hope the results of automatic testing with popular terminals will help decide what weight the performance vs. correctness tradeoff. I predict most popular terminals or libraries do not support any ZWJ at all.

Work remaining,

• [x] Update bin/wcwidth-browser.py to use and render tables of EMOJI_ZWJ_SEQUENCES by version.
• [x] Write automatic tests for ZWJ behavior and and new width() function, returning to 100% coverage.
• [x] Write interactive program that automatically checks all of those sequences, and some other ZWJ such as Bengali phrases with the current terminal, and writes some kind of report file about current os+terminal and detected wide-character and ZWJ emoji support level, to support the activity like was done with this tool and report https://github.com/jquast/ucs-detect#wcwidth-support-in-terminals
• [x] test some terminals, the most popular, how well do they support these sequences, at what "Emoji version" level, if any?
• [x] update docs/intro.rst to suggest wcwidth.width() function in the example. Write small section about POSIX wcwidth and wcswidth functions, why they exist for function signature compatibility for POSIX, but why they are not suggested due to the final -1 return value on error.
• [x] Update docstrings of wcwidth and wcswidth with deprecation warning in docstring only, to suggest using width() instead, with reference to the POSIX section for the reason.

[codecov[bot]]

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Files	Coverage Δ
wcwidth/emoji_zwj_sequences.py	100.00% <ø> (ø)
wcwidth/table_wide.py	100.00% <ø> (ø)
wcwidth/table_zero.py	100.00% <ø> (ø)
wcwidth/unicode_versions.py	100.00% <ø> (ø)
wcwidth/wcwidth.py	94.68% <83.33%> (-5.32%)	:arrow_down:

:loudspeaker: Thoughts on this report? Let us know!.

[jquast]

Sorry, no need to review, I have been using this branch for multiple ideas. I will carve them into smaller PR's, beginning with the automatic tests.

I am just performing automatic tests against popular terminals, now, and committing their results, when I'm finished with that I'll start smaller PR's, thank you!