video: remove slice based filtering and video output

Slices allowed filtering or drawing video in bands (or, in theory,
blocks). This allowed working on the video in smaller units. In theory,
this could bring a performance win by lowering cache pressure, as you
didn't have to keep the whole video in cache while filtering, but only
the slice.

In practice, the slice code path was barely used for the following
reasons:
- Multithreaded decoding with ffmpeg didn't output slices, because the
  ffmpeg slice callback can be called from another thread, and the
  mplayer video chain is not thread-safe.
- Most filters didn't actually support slices.
- There was nothing that would turn "full" images into appropriate
  slices.

On the other hand, supporting slices leads to code duplication and more
complex code, remove them.
vf: use talloc to allocate vf_instance
vf_screenshot: simplify, fix bugs

Remove direct rendering capability from this filter. There's absolutely
no reason why this filter should support DR, other than maybe allowing
the filter before vf_screenshot doing DR into the filter after it.

Fix handling of anamorphic screenshots, apparently this was forgotten in
commit c62efc52c6c5.

Make sure MP_IMGFLAG_ALLOCATED is not set on the image returned to
screenshot.c, as by convention screenshot.c assumes it can change the
image data if this flag is set. (When taking screenshots with subs.)
mp_image: cleanup: remove some unused flags

MP_IMGFLAG_ACCEPT_WIDTH and MP_IMGFLAG_COMMON_STRIDE are completely
unused. MP_IMGFLAG_COMMON_PLANE is used by vo_opengl_old only
(internally), and can be a bit relaxed.
vf_flip: remove DR capability

This is worthless. Flipping is still a virtually free operation
without DR.

The only disadvantage of removing this is that filters after vf_flip
can't pass buffers upwards to filters before vf_flip.
vf_swapuv: remove DR capability

Same as vf_flip.
libmpcodecs: simplify codec pixel format handling

Simplify the codec pixel format handling a bit by making it handle only
the case vd_ffmpeg needs: a video stream always decodes to a single
pixel format. The pixel format is unknown, until at least one video
packet is actually decoded.

Remove the handling for multiple pixel formats, and remove the
codecs.conf pixel format declarations that are left.

Remove the handling of "ambiguous" pixel formats like YV12 vs. I420 (via
VDCTRL_QUERY_FORMAT etc.). This is only a problem if the video chain
supports I420, but not YV12, which doesn't seem to be the case anywhere.
vd_ffmpeg: do not use mpcodecs_get_image(), fixes video format changes

mpcodecs_get_image() (which calls vf_get_image()) doesn't deal well
with pixel format changes. Unlike the video filter chain, vd_ffmpeg is
not destroyed and recreated on pixel format changes. This basically
means mpcodecs_get_image() can't be used in this case.

The DR path is untouched, and probably doesn't handle this either. If
this case happens, the newly added assertion will trigger.
vd_ffmpeg: remove weird inactive code

It's not clear why this was needed. It was added in 2002, and the
condition should always evaluate to false. It isn't needed for playing
422p material.

This triggered the bug fixed in the previous commit: chroma_y_shift
should be 0 with 422p, but it wasn't when a video switched from 420p to
422p, because the mpi still used the previous image format. This
resulted in the chroma strides being messed up.
vd_ffmpeg: cosmetics: move debugging code out of the way

Relatively useless statistics printing code was stuffed directly into
the middle of the central decode() function. Move it away.