[input-] fix editline() for characters having screen width > 1

[midichef]

The input editor assumes characters have a screen width of 1. For double-width characters like あ, many alignment artifacts show up on screen. For example, edited values can extend 1 character past the edge of a visidata cell. Or after pressing =, pasting several double-width characters into the input field, will cause ellipses … to show up on the right side of the input. And scrolling horizontally within a cell, some characters are not visible when the cursor is on them.

To demonstrate some of the issues, open a sample sheet with:
echo "12345678901234567890\nＡＢＣＤＥＦＧＨＩＪ０１-２--３---４--５--６--７--８-９" |vd -f tsv -
The header is single-width ASCII. The row is double-width letters and numbers, with single width dashes.
Shrink the cell with z_ 10. Then e and then press Right many times to see the problems. For example, after scrolling all the way right with End, the last character, ９, cannot be seen.

This PR fixes all known alignment issues in InputWidget.editline() for such characters. To handle the case where the screen does not have width to show a character with width > 1 at the start or end of the cell, extra … characters will appear. For example, if a cell is 1 column too small to show …ＡＢＣＤ…, the ellipses on the right side can be repeated in the column where Ｄ would otherwise start (because Ｄ takes up 2 columns and can't fit into the one on screen): …ＡＢＣ…… Or the ellipses on the left side can be repeated in the column where Ａ would otherwise finish: ……ＢＣＤ…

(I am happy to finally be doing the len() vs dispwidth() audit that I originally scheduled for summer 2023.)

[saulpw]

I'm glad you're doing the dispwidth audit, @midichef. It definitely has been a long time coming.

This particular code though is already pretty complicated, and I'm worried these improvements exceed the code budget here. Is this the essential complexity of accounting for wide characters when truncating a displayed string? I'm wondering if there's a single function like partition that can cover this ground with less cognitive overhead. Do you have a list of the known cases that were problematic? I'd like to put those into a unit test for whatever function(s) we eventually come up with.