Draft: clock: rework input/output startup

This MR rework the way the clock is started.

There were currently two kinds of vlc clocks: master clock and slave clock. This MR brings another characteristic to those clocks: input clock and output clock.

Output clocks will need to wait for the input clock to be started before starting themselves, regardless of whether they are master or slave. Output clock start will also be used to setup monotonic start when one of the output is driving the clock bus instead of relying on vlc_clock_ConvertToSystem, which was previously also called from filters and decoders.

By using an offset from the start_date, some other state variables like main_clock->offset are now normalized to alway start from 0 instead of starting from any value depending on vlc_tick_now(). It means that we can have much more interpretability from displaying any of start_time (which could help display start time discontinuity or slow buffering) or offset (now showing how much drift we get from the monotonic clock evaluation) compared to the previous values they got.

In addition, the clock start doesn't need a reset beforehand anymore. Most notably, this makes the starts with input clock master using the input clock reference points instead of starting with a monotonic clock. Unfortunately, it is breaking the start of the playback with --clock-master=input when a paceable media (file:// for instance) is played, most probably because buffering gets broken a bit through the input_clock_GetWakeup() computation since we still don't have the buffering linked to the vlc_clock bus yet.

Finally, some of the changes are made to put more rationale in how the startup values are setup and used. Clock dejitter handling also starts to change since output_dejitter handling doesn't make sense for input clock (since it adds arbitrary drift non-uniformly) and input_dejitter mainly includes the pcr_delay values for output monotonic start.

The MR is still at draft stage because some additional changes are needed for the sout, some tests need fixing at the end of the branch (startup date change with i_buffering_duration breaks the input dejitter computations), and more tests are needed to test cases with extra-buffering and preroll. But I'd like to inquire whether the change makes sense for everyone.

Co-authored-by: Thomas Guillem thomas@gllm.fr