top: if line editing, account for invisible characters

top: if line editing, account for invisible characters

If we're deleting a character or operating in overtype
mode, we must account for the potential of 'invisible'
characters. When one follows any character about to be
deleted or replaced both multi-byte sequences must go.

Without this change, there exists the possibility that
top might report some error where no error is apparent
to the user. For example, with 'other filtering' (o/O)
the user could see "unrecognized field name 'COMMAND'"
where the quoted column name appears perfectly normal.

Or maybe a sequences like the 'combining acute accent'
gets applied to an existing character instead of being
deleted as one expects when its parent was eliminated.

So, henceforth whenever any character is being deleted
we will now check for a following 'invisible' sequence
then eliminate it along with that preceding character.

[ admittedly, these scenarios are very rare yet they ]
[ may occur, especially when recalling some previous ]
[ multi-byte strings for editing. and, since we will ]
[ be interacting with a user, performance won't be a ]
[ factor so extra checks for a zero wcwidth is fine. ]

Signed-off-by: Jim Warner <james.warner@comcast.net>