Fixes #8821

Close #8511

This supports brightness, contrast, saturation and hue.

(same as OpenGL shaders)

This will be used for deinterlacing.

This is for advanced filtering on the GPU. So far, only progressive
scan is implemented.

This is a corner case. The picture needs to be copied back to the main
memory from the decoding GPU, and from there onto the rendering GPU.

...instead of copying YCbCr planes back to the main memory.

This avoids loosing the picture context if there is one. If the
original picture has no context, it makes no difference whether the
original or the copy is kept since blending failed anyway.

If the picture copy fails or blending is unavailable(1), discard only
the subpicture and keep the original picture.

(1) In practice, this never happens as the blender object is kept
all the time even without a "blend" module.

This provides colour space conversion, cropping and scaling of existing
video surfaces (as would come from a hardware decoder).

This enables using the pass-through hardware-accelerated decoder (from
a later commit) with transcode in stream output or with a video output
that does not support VDPAU surfaces.

This uses a VDPAU presentation queue to render VDPAU output surfaces
(i.e. screen-scaled RGBA pictures) on an X11 window. It is assumed that
a video filter will eventually convert pictures in the source video
format to VDPAU output surfaces of adequate dimensions.

The common VLC XCB event handling is used for X11 matters.

This enables importing I420, YV12, NV12, YUYV and UYVY pictures into
the GPU's VDPAU back-end. Conversion to RGBA color space and scaling to
the target resolution are performed on the fly by the GPU.