input: decoder: ensure decoder can be flushed

Flush was mostly entirely executed from the decoder thread, which meant
that it was blocked by previous call from decoder_t::pf_decode. Since
the decoder_t::pf_decode could be blocked waiting for a picture from the
vout to be able to resume decoding, and that flushing the video output
was done in this thread, it could deadlock.

A previous mechanism, picture_pool_Cancel, was introduced to allow the
external code to cancel the picture pool from the core and ensure
pf_decode would stop as soon as possible, but it was leading to more
spurrious unhandleable errors and could not work with decoder owning
their own pool.

Instead, ensure we set the flushing state directly from the flush call,
and flush the outputs. Setting the state will prevent decoder from
queueing new pictures by discarding them directly, which means that we
don't need to flush after flush has happened, and the flushing state
will be reset before new frames are queued into the decoder.

Fixes #26915

Co-authored-by: Thomas Guillem <thomas@gllm.f>