audio: move decoder context from sh_audio into new struct

Move all state that basically changes during decoding or is needed in
order to manage decoding itself into a new struct (dec_audio).

sh_audio (defined in stheader.h) is supposed to be the audio stream
header. This should reflect the file headers for the stream. Putting the
decoder context there is strange design, to say the least.
audio: don't write decoded audio format to sh_audio

sh_audio is supposed to contain file headers, not whatever was decoded.
Fix this, and write the decoded format to separate fields in the decoder
context, the dec_audio.decoded field. (Note that this field is really
only needed to communicate the audio format from decoder driver to the
generic code, so no other code accesses it.)
player: remove printing of barely correct slave mode stream info

This was printed before something was decoded, and thus was not really
correct. Also, this code is hilariously broken:

        /* Assume FOURCC if all bytes >= 0x20 (' ') */
        if (sh_audio->format >= 0x20202020)
            mp_msg(MSGT_IDENTIFY, MSGL_INFO,
                   "ID_AUDIO_FORMAT=%.4s\n", (char *)&sh_audio->format);

Time to kill it.

This information can be accessed through properties instead.
audio: remove ad_driver.preinit

This never had any real use. Get rid of dec_audio.initialized too, as
it's redundant.
video: move struct mp_hwdec_info into its own header file

This means most code accessing this struct must now include hwdec.h
instead of dec_video.h. I just put it into dec_video.h at first because
I thought a separate file would be a waste, but it's more proper to do
it this way, as there are too many files which include dec_video.h only
to get the mp_hwdec_info definition.
video: merge vd.c into dec_video.c

I don't feel like the separation ever made sense, and it was hard to
tell which file a function you were looking for was in.
options: provide a way for --vf to print custom help

Useful in rather special situations. See following commits.
video: remove vf_pp auto-insertion

This drops the --pp option, which was probably broken for a while. The
option automatically inserted the "pp" filter. The value passed to it
was ignored (which is probably broken, it always selected maximal
quality).

Inserting this filter can be done simply with --vf=pp, so this is not
needed anymore.
options: implement --pphelp differently

Make it work via --vf=pp:help instead.
options: don't prefix sub-options with "--" in help output

Commit 0cb9227a added this to the option list help output, but it looks
strange with sub-options.
options: print lavfi filter list with --vf=lavfi=help
video: move decoder context from sh_video into new struct

This is similar to the sh_audio commit.

This is mostly cosmetic in nature, except that it also adds automatical
freeing of the decoder driver's state struct (which was in
sh_video->context, now in dec_video->priv).

Also remove all the stheader.h fields that are not needed anymore.
player: rearrange how subtitle context and stream headers are used

Use sh_stream over sh_sub. Use dec_sub (and mpctx->d_sub) instead of the
stream header. This aligns the subtitle code with the recent audio and
video refactoring.

sh_sub still has the decoder context, though. This is because we want to
avoid reinit when switching segments with ordered chapters. (Reinit is
fast, except for creating the ASS_Renderer, which in turn triggers
fontconfig.) Not sure how much this matters, though, because the initial
segment switch will lazily initialize the decoder anyway.
demux: remove gsh field from sh_audio/sh_video/sh_sub

This used to be needed to access the generic stream header from the
specific headers, which in turn was needed because the decoders had
access only to the specific headers. This is not the case anymore, so
this can finally be removed again.

Also move the "format" field from the specific headers to sh_stream.
dec_video: remove "initialized" field

It's redundant.
dec_video: make vf_input and hwdec_info statically allocated

The only reason why these structs were dynamically allocated was to
avoid recursive includes in stheader.h, which is (or was) a very central
file included by almost all other files. (If a struct is referenced via
a pointer type only, it can be forward referenced, and the definition of
the struct is not needed.) Now that they're out of stheader.h, this
difference doesn't matter anymore, and the code can be simplified.

Also sneak in some sanity checks.
ao_rsound: fix option types

These are option values, and the option code expects char*.

Not actually tested.
video: move handling of container vs. stream AR out of vd_lavc.c

Now the actual decoder doesn't need to care about this anymore, and it's
handled in generic code instead. This simplifies vd_lavc.c, and in
particular we don't need to detect format changes in the old way
anymore.
video: don't overwrite demuxer FPS value

If the --fps option was given (MPOpts->force_fps), the demuxer FPS value
was overwritten with the forced value. This was fine, since the demuxer
value wasn't needed anymore. But with the recent changes not to write to
the demuxer stream headers, we don't want to do this anymore. So
maintain the (forced/updated) FPS value in dec_video->fps.

The removed code in loadfile.c is probably redundant, and an artifact
from past refactorings.

Note that sub.c will now always use the demuxer FPS value, instead of
the user override value. I think this is fine, because it used the
demuxer's video size values too. (And it's rare that these values are
used at all.)
audio: respect --end/--length with spdif passthrough

In theory, we can't really do this, because we don't know when a spdif
frame ends. Spdif transports compressed audio through audio setups that
were originally designed for PCM only (which includes the audio filter
chain, the AO API, most audio output APIs, etc.), and to reach this
goal, spdif pretends to be PCM. Compressed data frames are padded with
zeros, until a certain data rate is reached, which corresponds to a
pseudo-PCM format with 2 bytes per sample and 2 channels at 48000 Hz.
Of course an actual spdif frame is significantly larger than a frame
of the PCM format it pretends to be, so cutting audio data on frame
boundaries (as according to the pseudo-PCM format) merely yields an
incomplete and broken frame, not audio that plays for the desired
duration.

However, sending an incomplete frame might still be much better than the
current behavior, which simply ignores --end/--length (but still lets
the video end at the exact end time).

Should this result in trouble with real spdif receivers, this commit
probably has to be reverted.