demux_mkv: fix out of range comparison

This check was always false:

    if (num == EBML_UINT_INVALID)

Fix it by using the proper type for the num variable.

This case actually doesn't really matter, and this is just for hiding
the warning and for being 100% correct.
input: fix handling of MP_KEY_STATE_DOWN

VOs can use the MP_KEY_STATE_DOWN modifier to pass key up/down events to
input.c, instead of just simple key presses. This allows doing key auto-
repeat handling in input.c, if the VO doesn't want to do that.

One issue is that so far, this code has been used only for mouse events,
even though the code was originally written with keyboard keys in mind.
One difference between mouse keys and keyboard keys is that the initial
key down should not generate an input command with mouse buttons
(input.c did that), while keyboard events should (input.c didn't do
that). Likewise, releasing a key should generate input commands for
mouse buttons releases, but not for the keyboard.

Change the code so mouse buttons (recognized via the MP_NO_REPEAT_KEY
flag) follow the old hehavior, while other keys generate input commands
on key down, but not on key release.

Note that a key release event is posted either using
MP_INPUT_RELEASE_ALL, or a normal key press event after having sent a an
event with MP_KEY_STATE_DOWN. This is probably a bit confusing, and a
MP_KEY_STATE_RELEASE should be added.

Fix shift-handling with MP_KEY_STATE_DOWN as well.
input: reduce amount of tracked keys per binding

There's no need for key bindings that consist of 32 keys held down. It's
ridiculous and wastes memory.
input: don't let multi-key bindings block simple key bindings

Key bindings can include mutiple keys at once (additional to key
modifiers like ctrl etc.). This becomes annoying when quickly switching
between two bound keys, e.g. when seeking back and forth, you might end
up hitting the "left" and "right" keys at once. The user doesn't expect
to invoke the key binding "left-right", but would prefer a key stroke to
invoke the binding it was supposed to invoke.

So if there's no binding for a multi-key combination, try to find a
binding for the key last held down. This preserves the ability to define
multi-key combinations, while the common case works as expected.
input: change default auto-repeat settings

Rather arbitrary, but reasonable.
input: adjust wait time for key-repeat

Basically, these are additional timers that can expire without making
the central select() exit.
input: don't reset time on each key repeat

Key repeats were skipped when playloop iterations took too long. Fix
this by using the total times for key repeat calculation, instead of the
time difference to the last key repeat event.
x11: use mpv internal key auto-repeat handling if possible

Block X11's native key repeat, and use mpv's key repeat handling in
input.c instead.

No configure check for XKB. Even though it's an extension, it has been
part of most (all?) xlibs since 1996. If XKB appears to be missing,
just refuse enabling x11.

This is a potentially controversial change. mpv will use its own key
repeat rate, instead of X11's. This should be better, because seeking
will have a standardized "speed" (seek events per seconds when keeping
a seek key held down). It will also allow disabling key repears for
certain commands, though this is not done anywhere yet.

The new behavior can be disabled with the --native-keyrepeat option.
mplayer: apply hrseek framedrop only when doing hrseek

It's not sure if there's anything that could trigger this accidentally.
Normally this can't happen, because hrseek ends always if the PTS is
large enough, the same condition which disables framedrop. Seeking
resets hrseek framedrop anyway.

On the other hand, this change makes the code easier to understand,
and might be more robust against weird corner cases.
core: add backstep support

Allows stepping back one frame via the frame_back_step inout command,
bound to "," by default.

This uses the precise seeking facility, and a perfect frame index built
on the fly. The index is built during playback and precise seeking, and
contains (as of this commit) the last 100 displayed or skipped frames.
This index is used to find the PTS of the previous frame, which is then
used as target for a precise seek. If no PTS is found, the core attempts
to do a seek before the current frame, and skip decoded frames until the
current frame is reached; this will create a sufficient index and the
normal backstep algorithm can be applied.

This can be rather slow. The worst case for backstepping is about the
same as the worst case for precise seeking if the previous frame can be
deduced from the index. If not, the worst case will be twice as slow.

There's also some minor danger that the index is incorrect in case
framedropping is involved. For framedropping due to --framedrop, this
problem is ignored (use of --framedrop is discouraged anyway). For
framedropping during precise seeking (done to make it faster), we try
to not add frames to the index that are produced when this can happen.
I'm not sure how well that works (or if the logic is sane), and it's
sure to break with some video filters. In the worst case, backstepping
might silently skip frames if you backstep after a user-initiated
precise seek. (Precise seeks to do indexing are not affected.)

Likewise, video filters that somehow change timing of frames and do not
do this in a deterministic way (i.e. if you seek to a position, frames
with different timings are produced than when the position is reached
during normal playback) will make backstepping silently jump to the
wrong frame. Enabling/disabling filters during playback (like for
example deinterlacing) will have similar bad effects.