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:      4278 ns/iter (+/- 38)
test ringbuf::tests::bench_iter_1000                       ... bench:      1074 ns/iter (+/- 15)
test ringbuf::tests::bench_mut_iter_1000                   ... bench:      1074 ns/iter (+/- 7)
test ringbuf::tests::bench_new                             ... bench:        19 ns/iter (+/- 0)
test ringbuf::tests::bench_pop_100                         ... bench:       145 ns/iter (+/- 2)
test ringbuf::tests::bench_pop_front_100                   ... bench:       229 ns/iter (+/- 1)
test ringbuf::tests::bench_push_back_100                   ... bench:       178 ns/iter (+/- 0)
test ringbuf::tests::bench_push_front_100                  ... bench:       171 ns/iter (+/- 0)
```
I gave the technique used in `table::Bucket::next` a try and was surprised to find it is significantly slower. There could be a flaw in how I implemented it.

Using the `wrap_index` function returns a result of 634ns, where the technique used in `table::Bucket::next` return a result of 1082ns.

```rust
pub struct MutItems<'a, T:'a> {
    headptr: *mut T,
    tailptr: *mut T,
    tail: uint,
    head: uint,
    cap: uint,
    marker: marker::ContravariantLifetime<'a>,
    marker2: marker::NoCopy
}
```

```rust
#[inline]
fn next(&mut self) -> Option<&'a mut T> {
    if self.headptr == self.tailptr {
        return None;
    }

    let maybe_wraparound_dist = (self.tail ^ (self.tail + 1)) & self.cap;
    // Finally, we obtain the offset 1 or the offset -cap + 1.
    let dist = 1i - (maybe_wraparound_dist as int);
    self.tail += 1;
    let ptr = self.tailptr;

    unsafe {
        self.tailptr = self.tailptr.offset(dist);
        Some(&mut *ptr)
    }
}
```