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:      4005 ns/iter (+/- 96)
test ringbuf::tests::bench_iter_1000                       ... bench:       657 ns/iter (+/- 7)
test ringbuf::tests::bench_mut_iter_1000                   ... bench:       633 ns/iter (+/- 7)
test ringbuf::tests::bench_new                             ... bench:        15 ns/iter (+/- 0)
test ringbuf::tests::bench_pop_100                         ... bench:       210 ns/iter (+/- 0)
test ringbuf::tests::bench_pop_front_100                   ... bench:       179 ns/iter (+/- 1)
test ringbuf::tests::bench_push_back_100                   ... bench:       187 ns/iter (+/- 1)
test ringbuf::tests::bench_push_front_100                  ... bench:       174 ns/iter (+/- 2)
```
Any reason to not use `ptr::copy_memory` for these? (I think you can actually even use `copy_nonoverlapping_memory` based on my very formal consideration of your sweet ascii diagrams). A slightly more formal argument notes that the data is always being moved to the "new" half of the array, which is uninitialized by definition.