Move RingBuffer operations into RingBufferData

Currently, any types that directly embed/extend RingBufferData would not
be able to reuse the existing functionality, because it's defined on
RingBuffer. As such, this is necessary, even though it adds an extra
level of depth in the call stack.
Remove unnecessary unsafe modifier from various RingBufferData functions

These functions were created by migrating functionality from RingBuffer
to RingBufferData. Unlike RingBuffer, RingBufferData doesn't allow
concurrent access to the functions, so there's no potential for data
races when using it in safe code. I hadn't noticed this distinction at
the time I moved them.
Document justifications for some other uses of unsafe keyword
SequenceNumber: Fix a comment typo
Add missing whitespace
Fix a comment typo, expand explanation
Move nextN and releaseN functions to underscore naming convention

Previously, the naming convention of these functions was inconsistent
with the rest of the code.
Factor out availability caching into a trait

The sheer amount of code that needed to be added just to make this work
is prohibitive. I will likely revisit this choice later.
Merge CachingSequenceBarrier trait into SequenceBarrier

This reduces the amount of needless boilerplate a bit.
Factor out RingBufferTrait to allow alternative ring buffer types

This allows for the use of a linked-list style resizable ring buffer
containing a link to a larger buffer allocation, instead of the current
fixed-size ring buffer.
Make RingBufferTrait::get take a mutable self reference

This is necessary for consumers to be able to transparently start using
larger buffers allocated by the publisher.
Reword doc comment on next_n_real
Add ring buffer parameter to SequenceBarrier next functions

This isn't used currently, but it's needed to cleanly implement buffer
resizing functionality, given the current code structure.
Rename setDependencies function to set_dependencies
Make SinglePublisher/Consumer generic wrt SequenceBarrier implementation

This change expands the use of the SequenceBarrier trait within
SinglePublisher, SingleConsumer, and SingleFinalConsumer, such that it
is now possible to use other implementations of SequenceBarrier instead
of SinglePublisherSequenceBarrier and SingleConsumerSequenceBarrier.
Rename SinglePublisher/Consumer/FinalConsumer, removing Single prefix

These types are now generic enough that it's possible to implement
variations solely using different barrier and ring buffer
implementations. It makes sense for the names to reflect that.
Remove TODO comment about immutable dependencies

Adding constraints around dependency assignment isn't good use of time:
the dependency chain is always cyclic, so it would take an undue amount
of care to design a way to assign dependencies at construction time.
Move ring buffer reference into SinglePublisherSequenceBarrier

It is fairly clear to me now that it was misguided to try to separate
the barrier types from the ring buffer itself. Although currently, the only
necessary parameter is the buffer size, a mutable reference to the ring buffer itself is required to implement resizing. With that case, it is simpler to just store the ring buffer as a member of the barrier type, not as a member of the Publisher and Consumer types.
Remove buffer_size field from SinglePublisherSequenceBarrier

Now that the ring buffer is an accessible part of
SinglePublisherSequenceBarrier, a copy of the size is no longer needed.
Remove out-of-date type parameter from Publisher::new doc comment