mixer: minor refactoring

Let struct mixer access access MPOpts to simplify some things. Rename
some variables and functions. There should be no functional changes.
mixer, af_volume: use linear values instead of dB

Softvol always used a linear multiplier for volume control. This was
converted to dB, and then back to linear in af_volume. Remove this non-
sense. We still try to keep the command line argument to af_volume in
dB, though.
mixer: refactor, fix some aspects of --volume handling

Refactor how mixer.c does volume/mute restoration and initialization.
Move to handling of --volume and --mute to mixer.c. Simplify the
implementation of these and hopefully fix bugs/strange behavior related
to using them as file-local options (this uses a somewhat dirty trick:
the option values are reverted to "auto" after initialization). Put most
code related to initialization and volume restoring in probe_softvol()
and restore_volume(). Having this code all in one place is less
confusing.

Instead of trying to detect whether to use softvol at runtime, detect it
at initialization time using AOCONTROL_GET_VOLUME (same with mute,
AOCONTROL_GET_MUTE). This implies we expect SET_VOLUME/SET_MUTE to work
if the GET variants work. Hopefully this is always the case.

This is also preparation for being able to change volume/mute settings
if audio is disabled, and for allowing restoring value with playback
resume.
mixer: don't unmute audio when raising volume

This is rather strange behavior, away with it.
mixer: restore volume with playback resume

Note that this is intentionally never done if the AO or softvolume is
different, or if the current volume control method is thought to control
system wide volume (such as ALSA) or otherwise user controllable (such
as PulseAudio). The intention is to keep things robust and to avoid
messing with the user's audio settings as far as possible, while still
providing the ability to resume volume if it makes sense.
manpage: af_volnorm was renamed
mixer: allow accessing volume and mute property on disabled audio

The volume is set as soon as the audio chain is created again. This
works only in softvol mode. For system wide volume or otherwise
externally user controllable volume, this code is intentionally
disabled. It would be extremely weird if changing volume (while audio is
not initialized) would do nothing, and then suddenly change it when the
audio chain is created.

There's another odd corner case: the user-set volume will be thrown away
if it's set before the _first_ audio chain initialization. This is
because the volume restore logic recognizes a change from nothing to
softvol or an AO, and circumventing that would require additional code.
Also, we don't even know the start volume before that point.

Forcing the volume with --volume will can override the volume set during
no-audio mode, depending on the situation.
mixer: make struct opaque

Also remove stray include statements from ao_alsa and ao_oss.
af: merge af_reinit() and fix_output_format()

Calling them separately doesn't really make sense, and all existing
calls to them usually combined them. One subtitle difference was that
af_init() didn't wipe the filter chain if initialization of the chain
itself failed, but that didn't really make sense anyway.

Also remove af_init() from the code for setting balance in mixer.c. The
mixer should be in the initialized state only if audio is fully
initialized, so the af_init() call made no sense.

Note that the filter "editing" code in command.c doesn't really do a
nice job of handling errors in case recreating an _old_ (known to work)
filter chain unexpectedly fails, and this obscure/rare case might be
differently handled after this change.
Merge branch 'volume_restore'
ao_pulse: set the property media.role=video
ao_pulse: bug fix: goto the correct error handler
vf: fix filter initialization error check

vf_open returns 0 on error, 1 on success. Oops. Accidentally broken
with 6629a95.
vo/x11_common: don't require a working input method

Normally, we need this for Xutf8LookupString(). But we can just fall
back to XLookupString(). In fact, the code for this was already there,
the code was just never tested and was actually crashing when active
(see commit 2115c4a).
command: use a list of potential deinterlacer filters

Instead of hardcoding a single filter. This might be helpful for
modeling the vaapi deinterlacer as a video filter. The idea is that a
software deinterlacer would be tried first, and if that fails (because
vaapi hardware decoding uses HW surfaces, which a software deinterlacer
does not accept), the vaapi filter would be tried.
Merge remote-tracking branch 'upstream/master'

Conflicts:
	audio/mixer.c