Use a custom ringbuffer queue.

Substantial speed and memory improvements. Based on original code and suggestion
by Dariusz Górecki via https://github.com/eapache/channels/pull/3
Merge pull request #4 from eapache/fast-queue

Use a custom ringbuffer queue.
Be slightly less agressive in shrinking the queue.

The power of two is marginally more efficient to calculate, and the less
agressive bounds mean we have to reallocate+copy less. It does mean we might
waste slightly more memory when a large buffer is emptied, but given that
garbage-collection means old slices aren't necessarily freed immediately
anyways, that isn't a big deal.
Be more precise when copying the queue buffer.

Work out the logic more precisely to only copy exactly the elements we need.
Avoids an entire call to copy() when the queue doesn't wrap, and avoids copying
dead elements even when it does. Small but measurable performance improvement on
my benchmarks.
go fmt
Also shrink queue when exactly 1/4 full.

We would previously only shrink if it was strictly less than 1/4 full. It makes
no difference at all to the amortized cost per operation (even the constant
factor there-in), but it has another subtle effect: it ensures that the
backing-array is *always* a power-of-2 in length. This (probably) wastes
slightly less space on "slop" bytes caused by the memory allocator rounding up
on the size of allocation requests. It (probably) also plays slightly nicer with
cache lines etc.
Bump the minimum queue length to 16.

It doesn't add an unreasonable amount of extra space, and it *really* cuts down
on unnecessary 8-16-8 flipflopping that otherwise occurs. For example, it cuts
the number of "resize" calls when running "go test" on this package by more than
half.