Fixed bugs and improved overflow handling of AudioRingBuffer

Issue 1: AudioRingBuffer read and write pointers did not differentiate between a full buffer and an empty buffer (in either cases, those pointers are the same).

Fix: The underlying array of AudioRingBuffer was increased in size by 1 so that when the buffer is "full", the underlying array still has one element unused (i.e. the underlying array is never technically full).  This way, the write pointer will not overlap the read pointer when the buffer becomes full, allowing this case to be distinguished from an empty array.

Testing: unit test for AudioRingBuffer tests samplesAvailable() return values for full and empty arrays.


Issue 2: AudioRingBuffer writeData() would reset the buffer (empty it) if the new data would overflow it.

Fix: Instead, the new data would overwrite some old data and the ring buffer would become full.

Testing: unit test for AudioRingBuffer calls writeData() to overflow buffer and data is read back to confirm that old data was overwritten correctly


Issue 3: AudioRingBuffer addSilentFrame() did not check if the requested number of silent samples would overflow the buffer.  As a result, the write-pointer was advanced no matter what, which means it would sometimes "lap" the read-pointer, effectively erasing a bunch of data in the buffer.

Fix: A check was added so that if an overflow would occur, the number of silent samples is reduced just enough so that the buffer fills up to capacity without overflow occurring.

Testing: unit test for AudioRingBuffer calls addSilentFrame() to overflow buffer and data is read back to confirm a smaller number of silent samples were added than specified to fill the buffer.
I'm not really a fan of this. We probably need a better solution here. If there's a data type/class that the audio library depends on, then we should maybe move that class to the audio library and then the audio-mixer can use that version of the class. What did you need access to here?