mp_image: align image allocation height

vo_vdpau actually reads past the image allocation when displaying a
non-mod 2 420p image. The vdpau API specifies that VdpVideoSurfacePutBitsYCbCr()
requires a height that is a multiple of 4, and surface allocations are
automatically rounded.

So allocate video images with rounded height. libavutil does the same,
so images coming directly from the decoder or from libavfilter are no
problem. (libavutil does this alginment explicitly, not just because the
decoded image size is aligned to macroblocks.)
manpage: document af_* commands

Except af_cmdline, which is too questionable.
video: rename VDCTRL_RESET_ASPECT to VDCTRL_REINIT_VO

Same thing, and VDCTRL_REINIT_VO implies more generic use.
vd_lavc: change VDCTRL_REINIT_VO behavior

This tried to use ctx->pic (last decoded AVFrame) for the frame bounds.
However, if av_frame_unref() on the AVFrame is called, the function will
reset _all_ AVFrame fields, even those which are not involved with
memory management. As result, mpcodecs_config_vo() was called with 0
width/height, which made the function exit early, instead of
reconfiguring the filter chain.

Go back to using mpcodecs_config_vo() directly. (That's what it did
before this VDCTRL was originally introduced; the original reason for
it disappeared.)
m_option: allow using -vf-del with a name

Until now, -vf-del required a list of indexes. This was a bit
inconvenient, so add support for using filter names too. Also simplify
the code a bit, doing the change would have been too painful otherwise.
m_option: add -vf-toggle

Works like -vf-add, except if a filter already exists and has the same
parameters, it's removed instead of added.

Not really useful on the command line itself, but will make sense for
runtime filter changing in the following commit.
m_option: allow -vf ""

With the current semantics, there's no reason to disallow this.

(Although in my opinion, -vf should rather map to -vf-add than -vf-set,
however that is an independent issue from this change.)
core: allow changing filter filters at runtime

Add the "vf" command, which allows changing the video filter chain at
runtime. For example, the 'y' key could be bound to toggle deinterlacing
by adding 'y vf toggle yadif' to the input.conf.

Reconfiguring the video filter chain normally resets the VO, so that it
will be "stuck" until a new video frame is rendered. To mitigate this, a
seek to the current position is issued when the filter chain is changed.
This is done only if playback is paused, because normal playback will
show an actual new frame quickly enough.

If vdpau hardware decoding is used, filter insertion (whether it fails
or not) will break the video for a while. This is because vo_vdpau
resets decoding related things on vo_config().
video/filter: fix option parser memory leak

This happens only if an option actually allocates memory (like strings).

Change filter API such that vf->priv is free'd by vf.c instead by the
filters. vf.c will free the option values as well.
input: accept input command prefixes in any order

This is more consistent, and doesn't bother the user with ordering
rules when new prefixes are added.

Will break obscure uses of legacy commands: if the command is supposed
to be translated by the legacy command bridge, and if that command uses
one of the pausing* prefixes, the command can't be parsed. Well, just
use the new commands in this case.
input: do property expansion for all input command string arguments

Also add a "raw" prefix for commands, which prevents property expansion.
The idea is that if the commands are generated by a program, it doesn't
have to know whether the command expands properties or not.
input: allow quotes around any input command
vo_image: start image file numbers at 1

Requested by a user.