This fixes https://savannah.gnu.org/bugs/?48675.

(It may have been necessary in the past; there is no need for it now.)

This fixes https://savannah.gnu.org/bugs/?48633.

When doing an <Up> on the top line, or a <Down> on the bottom line of
the edit window, the affected lines have already been redrawn by the
scrolling code, so there is no need to do that again.

(However, that does not prevent the second line (or the last-but-one
line) from being redrawn unnecessarily when using the M-- (or M-+)
command elsewhere on the screen and /that/ line is horizontally
scrolled.  But we'll let that pass for now.)

For horizontal scrolling, it is not the /desired/ column position that
is relevant for determining whether a line needs to be redrawn after a
cursor movement, but the /actual/ column positions before and after.

This fixes https://savannah.gnu.org/bugs/?48627,
and fixes https://savannah.gnu.org/bugs/?48629.

Having two unneeded parameters in the tiny version is acceptable --
the code gets so much more readable.

This addresses https://bugs.debian.org/831636 reported by Christoph Biedl.

Leave the rest of any escape sequence to be processed normally, which
should be possible because those characters are all in ASCII range.

This fixes https://savannah.gnu.org/bugs/?48318.

These codes are the basic codes that get assigned for the movement keys
in the list of shortcuts -- they don't need any translation.

That is a task for the key-getting routine.

Again, just for preapring an easier return from the parsing routine.

There is no need to specially flag a function key or editing key --
the keycode is indication enough in itself: outside of byte range.

Saving roughly twenty microseconds at startup.

Also, when a key string does not denote a Ctrl nor Meta nor Function key,
there is no point in assigning a keycode, because plain characters cannot
be used as a function shortcut.

The keycode is not a sequence; it is a single integer value.

And instead of using two key types, just use a bool to indicate whether
a keystroke involves Meta.

A keycode is either already in byte range (so there is nothing to do)
or it is not and it shouldn't be (so there is nothing to do either).

After initialization, the type of a key is never used nor needed
(other than for meta keys).

Accept the "Esc [ 1 n ~" and "Esc [ 2 n ~" sequences only when they
end with the "~" character, not with any character.

It is nicer to have a predictable cursor position and not see it hop
left and right on differently indented lines.

Those lines don't exist in that mode -- the relevant subwindows are
smaller, or have been made smaller just before.

This fixes https://savannah.gnu.org/bugs/?48635.