Child clock improvements

[toots]

Description

This PR simplifies the handling of sub-clocks and sources belonging to sub clocks.

Generally, the way to handle sub-clocks become strictly through ticking the subclocks.

All sources associated with that clock will then be animated.

If a source is declared as a child source of interest, it is wrapped into an output and that output populates a buffer.

This allows multiple operators to read data from sub-source belonging to a subclock: if the clock needs to be ticked when the operator needs data, it is ticked and all the data generated during the tick is stored in a buffer.

Then, if another operator also needs data from a source inside that clock, if the clock has been ticked and some data was generated, then it can access that data without the need to tick the clock again.

Example

In this example, two inline encoders consume from different sources of the child clock.

When the main clock ticks, ffmpeg.encode.audio 1 can tick the child clock first, generating a fresh round of data for playlist, single and add.

Then, ffmpeg.encode.audio 2 can take the data buffered from the child tick generated by ffmpeg.encode.audio 1 and proceed without having to also tick the child clock.

Changes

Operating this way, the old Child_support and Producer_consumer APIs are merged into a single one. Also, Child_support now applies to a single source since all sources are now wrapped into their own output.

Lastly, a warning is issued when too much data accumulates in the child buffers.