input: decoder: fix flushing when deleting decoder

An input_decoder instance can be deleted while its DecoderThread, the thread calling decoder_t::pf_decode, is still running, meaning that the deletion request happens asynchronously to the decoding process.

In particular, when the input_decoder instance is being deleted, an aborting state is signalled to the DecoderThread and the input decoder joins the thread afterwards.

In order to return and be joined, the DecoderThread needs to finish what it was doing. In the case of a decoder, where input is paced by output availability, it's likely that the decoder will get paced and will be waiting on the decoder_t::pf_decode call. To finalize this call, the decoder must be provided pictures back from the output, so that the block from decoder_t::pf_decode can be queued.

At the beginning of the deletion, by setting p_owner->flushing to true, we also prevent the decoder implementation to queue blocks into the output (from commit 34a548cc). When flushing the input decoder, the output was also correctly flushed (tested by 91aabbf0) which matches with how the decoder implementation can be unblocked.

But in the case of closing, output flushing was only happening when the output was paused, meaning that a deadlock could happen if every pictures were queued to the output when the decoder would be deleted while it was decoding another new block.

This issue was reproduced with the Videotoolbox decoder.