Add timestamp circlebuf for video input/output

At the start of each render loop, it would get the timestamp, and then
it would then assign that timestamp to whatever frame was downloaded.
However, the frame that was downloaded was usually occurred a number of
frames ago, so it would assign the wrong timestamp value to that frame.

This fixes that issue by storing the timestamps in a circular buffer.
Fix bug removing output from its previous encoders

When the output sets a new audio/video encoder, it was not properly
removing itself from the previous audio/video encoders it was associated
with.  It was erroneously removing itself from the encoder parameter
instead.
Fix a bug where audio would not restart (outputs)

Apparently I unintentionally typed received_video = false twice instead
of one for video and one for audio.

This fixes a bug where audio would not start up again on an output that
had recently started and then stopped.
media-io: Fix repeating video timestamps

In video-io.c, video frames could skip, but what would happen is the
frame's timestamp would repeat for the next frame, giving the next frame
a non-monotonic timestamp, and then jump.  This could mess up syncing
slightly when the frame is finally given to an outputs.
util: Fix bug with darray_erase_range

Did not multiply the element size for the memory move operation.
Fix a major sync bug

This bug would happen if audio packets started being received before
video packets.  It would erroneously cause audio packets to be
completely thrown away, and in certain cases would cause audio and video
to start way out of sync.

My original intention was "don't accept audio until video has started",
but instead mistakenly had the effect of "don't start audio until a
video packet has been received".  This was originally was intended as a
way to handle outputs hooking in to active encoders and compensating
their existing timestamp information.

However, this made me realize that there was a major flaw in the design
for handling this, so I basically rewrote the entire thing.

Now, it does the following steps when inserting packets:

- Insert packets in to the interleaved packet array

- When both audio/video packets are received, prune packets up until the
  point in which both audio/video start at the same time

- Resort the interleaved packet array

I have tested this code extensively and it appears to be working well,
regardless of whether or not the encoders were already active with
another output.