Revert "Allow PiP when using a VAAPI playback profile"

The issue is in VAAPI decoder, so revert it for a better fix

This reverts commit 4a289572b54f076443f295cfae21f77e6d0f4d93.
Implement copying one VideoFrame into another where strides are different

copy(VideoFrame*, VideoFrame*) is buggy in that it simply copy the content of one frame into another, ignoring resolution and stride size.

For now, only handle copying a frame into another where the resolution is the same but the strides are different.
This is required for VAAPI Null video output as typically, the frame extracted doesn't have a stride equal to the width of the video, and instead is 32 bytes aligned.

Code could be optimised and SSE accelerated, to come
Fix VAAPI accelerated PiP

PiP wasn't possible with VAAPI playback. There was the issue that only one VAAPI context was allowed at a time, and then the frame retrieved couldn't be used as-is (fixed with 520b8bceb57235bba397fe7c15e12bc25f365ca5)

Drop VAAPI NV12 frame format support, the conversion to YV12 as it is is buggy and from a quick search/test, all VAAPI backends support either YV12 or YUV420P format, so there's no use for it anyway.