Remove decoder thread in stream output scenarios

This issue follows discussions that happened during the 2022 VLC workshop (summary in #26825 (closed)).

Summary

Problematic

Currently, an input decoder is spawned to handle both the display and the stream output. The input decoder has a lot of mechanisms that are unneeded by the stream output such as a specific thread used for decoding (sout does not need a decoder actually, just a packetizer in some scenarios), forwarding mouse events, etc.

Motivations

Having the stream output packetizing step handled synchronously would, in addition to make the code path simpler for stream output, help a lot for the implementation of SetPCR forwarding in stream output (see !1394 (merged)) as the async SetPCR handling could be done in transcode only!

Solution

The solution considered "the clean one" that was agreed on during the workshop was to create another es_out implementation specialized in stream output handling, thus, in theory, only packetizing frames synchronously and forwarding them to the stream output.

Proposition for VLC 4.0

The past week, I've been experimenting in making a stream output specific es_out implementation (asenat/es_out_sout). While it does work, my approach was naive and purely experimental. It appeared to me that, separating the stream output from the main display es_out was gonna need a lot of refactoring and making code common. Which probably imply regressions and long reviews.

While I do agree that a better separated es_out is the way to go, I can hardly see it happening for 4.0 as we are currently trying to stabilize the branch and not introduce to much changes in such critical parts of the core.

Another option that was mentioned by @tguillem was to tune the vlc_input_decoder to not spawn a decoder thread in stream output scenario and simply packetize synchronously. We believe that going this way for 4.0 before removing completely stream output from vlc_input_decoder in future versions is a better idea for now. This is hacky and adds in to the existing mess but is much less likely to introduce regressions in 4.0 and is trivial to implement. Having it implemented this way in 4.0 will allow us to introduce a clean version of SetPCR in stream output.

I'm putting this in an issue for eventual debates and discussions before submitting the vlc_input_decoder workaround in a draft MR (This should come in the week as it's not that big of a change code-wise).

TLDR

Implementing a stream output specific es_out needs too much refactor and code changes that will potentially be long to review and lead to unseen regressions for 4.0. The proposition is then to disable asynchronicity directly in the vlc_input_decoder in stream out scenario for vlc 4.0.