Bugfix: Variation Selector-16/ZWJ and starting sequences in wrap()

[jquast]

Closes #267.

1. Support emojis sequences, we already had automatic tests for them, but they have been adjusted to match that they are now "correct".

2. There was a long-standing bug, that if the first line of text sent to textwrap() begins with a sequence, that the sequence was lost!

3. Also match the "ST"-terminated variant of OSC 8 (hyperlink), rarely used, minor.

For "truncate" method, we just update it to the more complex technique used in wcwidth.wcswidth() to account for ZWJ and VS-16 and add covering tests.

For the other, we now use a translation table to remove any possible C0 or C1 control characters before calling wcwidth.wcswidth() directly to prevent defense against erroneous -1 return values, so we can call wcswidth directly, which fixes measurement of ZWJ and VS16.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.43%. Comparing base (0214108) to head (e891355).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #338      +/-   ##
==========================================
+ Coverage   98.42%   98.43%   +0.01%     
==========================================
  Files          11       11              
  Lines        2604     2627      +23     
  Branches      463      468       +5     
==========================================
+ Hits         2563     2586      +23     
  Misses         31       31              
  Partials       10       10              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jquast]

I found a bug in our implementation I will try to address in this branch, sequences are sometimes lost in rare cases.

Found while developing a blessed-free version of this to be included in the wcwidth library, jquast/wcwidth#169

[jquast]

I have tested a "non-blessed" version of our wrap(), ljust(), rjust(), and center() methods for inclusion in upstream library, wcwidth

• New: wrap() wcwidth#169
• New: ljust(), rjust(), center() justify text wcwidth#168
• New: width() terminal-aware string measurement wcwidth#166
• New: iter_graphemes() wcwidth#165

The above version is approximately 4-5x faster than blessed in my testing (on UDHR data), because it is not instantiating so many Sequence() temporarily and pre-processing with .padd(), but, instead running iterators for graphemes and sequences and tracking lots of indicies. Though alike, they are also a bit different in approaches. The use of grapheme clustering should fix line breaking on some languages that we may not be familiar with enough to test properly.

If they are accepted to wcwidth library, we should probably just bump our wcwidth requirement in blessed and outsource the logic to the wcwidth library and maintain it there, it will probably get more attention and help there.

Some key differences,

• blessed wraps text containing newlines, preserving their newlines. I chose to keep the exact same behavior as textwrap.wrap() and convert them to "soft spaces", sort of like html does.
• in conditions where linebreaks occur around sequences, but are followed by zero-width sequences, blessed puts them trailing on the previous line, while wcwidth wrap will put them leading onto the next line. This has a minor practical difference, and wcwidth's "sequences leading next line" is preferred, in the example case like one line at a time is displayed while switching attributes between line display, we want to match the next line's attribute.

[jquast]

One more key difference, wcwidth.width() measures different than blessed.length() did in regards to BACKSPACE \b,

• wcwidth's width() returns the maximum cursor extent - the rightmost column reached at any point, wcwidth.width("abc\b\b\b") == 3
• blessed's length() returns the effective length - after processing cursor movements destructively, blessed.Terminal().length("abc\b\b\b") == 1

When I migrated the code into wcwidth, my first pass had an option for "measure_width='extent' or 'cursor'" to provide both of these features, but I cut it out in the final version.

Because after careful review I think blessed is doing this wrong by default -- the most common use case is only, "how much screen real estate this takes up", and, likely to use direct cursor positioning yourself to display each wrapped/centered/etc line -- the ending position of the cursor has no consequence. If you wish to also know "what is the final cursor position" you are probably very low-level, like pyte.