vd_ffmpeg: do not mutate global threads option

This mutated the variable for the thread count option
(lavc_param->threads) on decoder initialization. This didn't have any
practical relevance, unless formats supporting hardware video decoding
and other formats were played in the same mpv instance. In this case,
hardware decoding would set threads to 1, and all files played after
that would use only one thread as well even with software decoding.
vd_ffmpeg, vo_vdpau: make hardware decoding not use our DR code path

VDPAU hardware decoding used the DR (direct rendering) path to let the
decoder query a surface from the VO. Special-case the HW decoding path
instead, to make it separate from DR.
vd_ffmpeg: remove codec DR

This was buggy and didn't even work in the simplest cases. It was
disabled when multithreading was used, and always disabled for h264.
It's also possible that DR actually works for some codecs.

Since there is barely any advantage to DR (especially with VO DR gone),
just remove it. It's woth mentioning that mplayer-svn seems to have a
working DR implementation, which has been fixed to work with h264.
ffplay and the ffmpeg command line tool use DR too if libavfilter is
enabled.

Note that when using in-place filters, we could gain an advantage by
using the ffmpeg DR interface: we could know whether a decoded image is
still needed by the decoder (e.g. it's a reference frame), or whether
in-place filtera can work directly on it and change the image data. This
may provide a motivation to actually add working DR, but it's probably
not worth the additional complexity.

Hardware decoding still uses the ffmpeg DR mechanism, but has been
decoupled from mpv's DR in the last commit.
vo_corevideo: use stride

In theory, the code was entirely correct, as the VO doesn't report
VFCAP_ACCEPT_STRIDE in query_format. But the rest of the video chain
didn't necessarily respect this.
vd_ffmpeg: minor simplification
vf_expand: remove DR capability
vf_sub: remove DR capability
vf: add functions to replace vf_get_image() and DR

Add a number of new functions, which will replace the functionality
currently provided by vf_get_image(). The functions do primitive buffer
management, taking typical use cases of existing filters into account.

They also provide a simpler form of direct rendering: instead of
allowing to pass an image buffer upwards the filter chain like
vf_get_image() does, the new functions assume that images passed down
the filter chain can be modified. This actually makes code simpler for
typical in-place filters. Filters have to explicitly set the
MP_IMGFLAG_PRESERVE flag if they output images that point to data which
must not be overwritten.
VF: use new functions instead of vf_get_image()

Switch all filters to use the new functions introduced in the previous
commit. This is all about replacing vf_get_image() calls.

vf_pullup.c possibly contains some non-sense code. It's evident that its
DR code never really worked (get_image is commented out), and it's not
really clear to me whether the inactive code (below the "FIXME") is
actually needed, and whether the filter is buggy, always was buggy, or
actually works fine.

vf_softpulldown.c had a bug: it assumed vf_next_put_image() would
basically copy the image, and that the image data could be overwritten
when returning from this call. This is not true at all, the following
situations can require the image (metadata + pixel data) to live longer:
- Most VOs "queue" one frame until it's actually known that the frame
  will be displayed and not discarded (or something like this). See how
  vo_draw_image() and vo_new_frame_imminent() work. vo_vdpau is the only
  VO which actually uploads all frames output by the filter chain
  immediately, because it does its own frame queuing. Consequently, the
  video output with -vf softpulldown was different with vo_vdpau and for
  example vo_opengl.
- Filters which use vf_queue_frame() actually store the put_image() mpi
  to use it later, after put_image() has returned.

There may be more fixed or newly introduced bugs in various filters.
video: remove things related to old DR code

Remove vf_get_image().

Remove some image flags, most of which are now useless or completely
unused.

Remove mp_image.width/height. The w/h members are the ones to use.
width/height were used internally by vf_get_image(), and sometimes for
other purposes. In some cases, using width/height was a bug (like in
vo_image.c), in other cases width/height were the same as w/h anyway.

Remove some other unused mp_image fields.

Some rather messy changes in vo_opengl[_old] to get rid of legacy
mp_image flags and fields. This is left from when vo_gl supported DR.