We don't use pending pictures anymore as they are all pushed during a call to
filter_chain_VideoFilterInto (and thus filter_chain_VideoFilter).

In the video output only the static filters are likely to push multiple
pictures in a single call. But they are put in a FIFO and treated one by one in
a loop later.

In other cases the number of output may multiply in a single call, in the worst
case scenario. But they are not time sensitive cases like the video output.

We assert that only one picture can be received by this picture chain.
Otherwise the caller should have used filter_chain_VideoFilterInto.

The difference of filter usage/expectations could be enforced by using two
different types.

For transcode+fps and user selected filters (we never know what the user will
manually add) the filter chains may output more than one picture per call. We
put all the results in a vlc_array and loop on that array to dequeue the
filtered pictures.

One array is for prerendered pictures (passed through "static" filters like
deinterlacing or fps), one array is for user filters. The final converter
should not receive more that one picture per call so we use
filter_chain_VideoFilter for that filter chain.

It can handle better the case of filters pushing more than one picture.

Use filter_chain_VideoFilterInto instead of filter_chain_VideoFilter, allowing
static filters to push multiple pictures.

Loop until we get a picture out of the static filters and there are pictures
coming from the decoder.

We use a picture_fifo_t because it can be flushed based on a date.

Intermediate filters send their output to a local sink filling

The old callback simulates a sink that chains the pictures with
vlc_picture_chain_Append and returns the front of the chain.

It's sending pictures with vlc_video_sink_PutPicture() rather than attaching
pictures to each other with vlc_picture_chain_AppendChain().

The old DoDeinterlacing() still works the same.

If a filter sending pictures to a sink send more than one picture to a sink,
the code will assert. It means filter_FilterSingle was used with a filter that
sends more than one picture. So filter_FilterSingle() should only be used with
safe filters, ie not user defined ones bu mostly converters. This is already
the case.

The filter chain receives the pictures and puts them in a FIFO (like filters used to)

Ultimately all filters will use this callback.

If the underlying filter outputs more than one picture it will assert. In the
real world, all these converters only output one picture per input, just like
the containers they are called from.

Rename the picture chains to make it clearer who does what.

Use vlc_picture_chain_t for the local picture chains, not a full
picture_fifo_t which is supposed to have a lock.

In some rare case it's necessary to get a picture chain under lock and clear
it right after, without holding the lock while each item is being processed.

This requires picture_GetAndResetChain to return the same type.