video: filter new frames at a better time

Move this code below the code that "shifts" the newly filtered frame.
This allows us to skip a useless playloop iteration later, because
obviously we need to filter a new frame after the previous frame has
been "shifted", and not before that.
video: check whether there are enough frames after filtering

Move the check to a function. Run the check a second time after
decoding/filtering. This second check is strictly speaking redundant
(which is why it wasn't done until now), but it avoids a useless
playloop iteration.
video: separate calling decoder/filter

Rename video_decode_and_filter to video_filter, and add a new
video_decode_and_filter function. This function now calls the decoder.
This is done so that we can check filters a second time after decoding,
which avoids a useless playloop iteration.

(This and the previous commits are really just microoptimizations, which
simply reduce the number of times the playloop has to recheck
everything.)
video/filter: allow better dataflow

Consider a filter which turns 1 frame into 2 frames (such as an
deinterlacer). Until now, we forced filters to produce all output frames
at once. This was done for simplicity.

Change the filter API such that a filter can produce frames
incrementally.
vf_lavfi: fetch output frames incrementally

Uses the new mechanism introduced in the previous commit.

Depending on the actual filter, this distributes CPU load more evenly
over time, although it probably doesn't matter.
input: add function for setting repeat info

Let us set a different rate and delay.

Needed for the following commit where we set rate and delay reported by weston.
But only if the option native-keyrepeat is set.
wayland: use reported rete and delay

If native-keyrepeat is true then we set the rate and delay reported by the
compositor.
build: update minimum wayland version

Uh oh.
input: add locking for repeat info
af_hrtf: initialize coefficient arrays

Sometimes, --af=hrtf produces heavy artifacts or silence. It's possible
that this commit fixes these issues. My theory is that usually, the
uninitialized coefficients quickly converge to sane values as more audio
is filtered, which would explain why there are often artifacts on init,
with normal playback after that. It's also possible that sometimes, the
uninitialized values were NaN or inf, so that the artifacts (or silence)
would never go away.

Fix this by initializing the coefficients to 0. I'm not sure if this is
correct, but certainly better than before.

See issue #1104.