Remove use of Option<T> inside of RingBuf

Fix for task in Metabug #18009

This changes much of about how RingBuf functions. `lo`, `nelts` are replaced by a more traditional `head` and`tail`. The `Vec<Option<T>>` is replaced by a bare pointer that is managed by the `RingBuf` itself. This also expects the ring buffer to always be size that is a power of 2.

This change also includes a number of new tests to cover the some areas that could be of concern with manual memory management.

The benchmarks have been reworked since the old ones were benchmarking of the Ring buffers growth rather then the actual test.

## Benchmark
**Before:**
```
test ringbuf::tests::bench_grow_1025                       ... bench:      9200 ns/iter (+/- 100)
test ringbuf::tests::bench_iter_1000                       ... bench:      1341 ns/iter (+/- 34)
test ringbuf::tests::bench_mut_iter_1000                   ... bench:      2250 ns/iter (+/- 44)
test ringbuf::tests::bench_new                             ... bench:        22 ns/iter (+/- 0)
test ringbuf::tests::bench_pop_100                         ... bench:       351 ns/iter (+/- 3)
test ringbuf::tests::bench_pop_front_100                   ... bench:      1169 ns/iter (+/- 61)
test ringbuf::tests::bench_push_back_100                   ... bench:       244 ns/iter (+/- 3)
test ringbuf::tests::bench_push_front_100                  ... bench:       246 ns/iter (+/- 5)
```
**After:**
```
test ringbuf::tests::bench_grow_1025                       ... bench:      2973 ns/iter (+/- 30)
test ringbuf::tests::bench_iter_1000                       ... bench:       630 ns/iter (+/- 3)
test ringbuf::tests::bench_mut_iter_1000                   ... bench:       627 ns/iter (+/- 9)
test ringbuf::tests::bench_new                             ... bench:        15 ns/iter (+/- 0)
test ringbuf::tests::bench_pop_100                         ... bench:       224 ns/iter (+/- 0)
test ringbuf::tests::bench_pop_front_100                   ... bench:       221 ns/iter (+/- 1)
test ringbuf::tests::bench_push_back_100                   ... bench:       236 ns/iter (+/- 0)
test ringbuf::tests::bench_push_front_100                  ... bench:       191 ns/iter (+/- 2)
```
The `rallocx` function (`reallocate`) currently hits the in-place allocation code path and then falls back to allocating + copying + deallocating. It would be *similar* to call `reallocate_inplace` (`xallocx`) and then fall back to allocating, copying and deallocating by hand.

With my outstanding Linux kernel patch, jemalloc is able to literally *move* the pages to the new location rather than copying. However, it would also be possible to call `mremap` with the proposed `MREMAP_RETAIN` flag on the vector allocation manually when it's above a certain size.