player: warn if PTS association mode switches

This normally shouldn't happen. It does happen with VfW-muxed mkv files,
and would normally happen with avi files (except that we force the
correct association mode using an explicit hack for avi).

This is usually prepended by warnings like:

 Decreasing video pts: 0.125000 < 0.167000

and after the switch, there should be no warnings anymore.

Background: avi likes to use DTS for timestamps instead of PTS.
Basically, there are no proper timestamps in the file, only frame
numbers. And Matroska is insane and stores the made-up DTS instead
of a proper PTS. This will be handled properly later.
video: pass PTS as part of demux_packet/AVPacket and mp_image/AVFrame

Instead of passing the PTS as separate field, pass it as part of the
usual data structures. Basically, this removes strange artifacts from
the API. (It's not finished, though: the final decoded PTS goes through
strange paths, and filter_video() finally overwrites the decoded
mp_image's pts field with it.)

We also stop using libavcodec's reordered_opaque fields, and use
AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because
these pts fields are not "really" opaque anymore, yet we treat them as
such. But the end result should be the same, and reordered_opaque is
marked as partially deprecated (it's not clear whether it's really
deprecated).
dec_video: fix function signature

Just why...? And why did this take 7 years?
player: change semantics of --no-correct-pts

Before this commit, this mode estimated the frame time by subtracting
successive packet PTS values. This is complete non-sense for video
codecs which use reordering. The code compensated frame times for these
non-sense using the FPS value, but confused the rest of the player with
non-sense jumping around timestamps. So, all in all this mode is not
very useful.

Repurpose this mode for fixed frame rate playback. This gives almost the
same behavior as the old mode with forced framerate (--fps option). The
result is simpler and often more robust.
player: merge no-correct-pts with correct-pts code

Now the --no-correct-pts mode is like the normal mode, just with
different timestamp calculations. The semantics should be about the
same as before this commit.
demux: export dts from demux_lavf, use it for avi

Having the DTS directly can be useful for restoring PTS values.

The avi file format doesn't actually store PTS values, just DTS. An
older hack explicitly exported the DTS as PTS (ignoring the [I assume]
genpts generated non-sense PTS), which is not necessary anymore due to
this change.
demux_lavf: disable genpts by default, remove the builtin genpts hack

This was needed to determine PTS from DTS, but the previous commits
make it unnecessary.

The builtin genpts hack was used for DVD, because libavformat's genpts
essentially went amok on DVD timestamp resets. See commit 65d87091 for
details.
video: disable PTS sorting fallback by default

It appears PTS sorting was useful only for avi files (and VfW-muxed
mkv). Maybe it was historically also important for decoders with broken
or non-existent PTS reordering (win32 codecs?). But now that we handle
demuxers which outputs DTS only correctly, it just seems dead weight.

Disable it by default. The --pts-association-mode option is now forced
to always use the decoder's PTS value. You can still enable the old
default (auto) or force sorting. But we will probably remove this option
entirely at some point.

Make demux_mkv export timestamps at DTS when it's in VfW mode. This is
needed to get correct timestamps with the new default mode. demux_lavf
already does that.
video: move timestamp determination code to dec_video

This means the code that tries to figure out the timestamp from
demuxer and decoder output is now all in dec_video.c. We set the
final timestamp on the returned image (mp_image.pts), as well as
the d_video->pts field.

The way the player uses d_video->pts field is still a bit messy. Maybe
this could be cleaned up later.
player: only pause for waiting on cache if it makes sense

If the value for --cache-on-pause is larger than --cache-min, and the
cache runs below --cache-on-pause, but above --cache-min, the logic
would demand to pause the player and then unpause immediately again.
This doesn't make much sense, and alternating the pause state in each
playloop iteration has negative consequences. Add an explicit check to
avoid this situation.
sub: respect detected language for fuzzy-matched external subtitles

Solve this by passing through the language to the player, which then
uses the generic subtitle selection code to make a choice.

Fixes #367.