More ways to define key sequences

[o.pikozh]

Currently, mc works in the following way:

• by default some set of sequences is recognized ('mc_default_keys');
• if TERM value starts with "xterm" (or some other predefined strings), some more sequences are recognized ('xterm_key_defines');
• if TERM value starts with "qansi-m", some more sequences are recognized ('qansi_key_defines').

However, such hard-coded way is not the best.

1. More terminal emulators with different key bindings may appear in future, you cannot hard-code all them now.
2. User may need some xterm-like key-sequences not only in xterm or xterm-compatible terminals. (But faking TERM=xtermyyy or passing --xterm/-x is not an option, because this causes not only key-handling-change, but also other changes behavior.)

Solutions:

1. At least, --xterm/-x flag must be split into several flags like --keys-as-in-xterm, --aaa-as-in-xterm, --bbb-as-in-xterm; --keys-as-in-qansi.
2. At most, xterm_key_defines/qansi_key_defines should be read from config files, e.g.:

   BRACKETED_PASTING_START = "\033[200~"
   BRACKETED_PASTING_END = "\033[201~"
   if xterm*|iris-ansi*|rxvt*|screen*
   

   F1 = "\033OP"
   [...]
   

   end
   if qansi-m
   

   CTRL+NPAGE = "\033[u"
   [...]
   

   end
   

Prehistory:
I was annoyed that Ctrl+Left and Ctrl+Right keys generate the same ascii codes as Left and Right on tty's (unlike in xterm; so bash can't recognize Ctrl+Left and Ctrl+Right on tty's, but can in xterm), so I modified system configs to force Ctrl+Left/Ctrl?+Right to generate on tty's exactly the same ascii codes as in xterm).
After that C-Left, C-Right stopped working in mc.
This itself is not a bug; it is expected behavior (I changed ascii codes -- and mc no more recognizes them -- obviously).
However, I expected to fix this by changing terminfo files (as C-Left, C-Right were still working in mc in xterm, I expected that different behavior of mc on tty1 and in xterm was caused by differences in "linux" and "xterm" terminfo files).
However, to my surprise, it appeared that mc's behavior depends on the value on the TERM environment variable itself, but not on the correspondent terminfo file.
And I cannot workaround this with -x because it introduces more serious bugs.