Further polish under-the-hood and docstrings.

The first change makes RateLimiter operate in constant time with
respect to the number of operations allowed per period.  Under the
current (and previous design as well), the amount of time required
per operation is primarily a function of the number of operations
allowed per unit of time (i.e., buffer/slice size).  Under the proposed
design, once RateLimiter is warmed up with requests, we can avoid
expensive O(n) copies by using a linked list and performing pointer
swapping instead.  The results of the benchmark are profound:

https://gist.github.com/matttproud/2d0ca7bbf2321cfd2b25

The second change is to enhance the docstrings and have them further
explain the contract that a user of the RateLimiter can expect: Bursty
refills, no smoothing, no warmup period, and no guarantees of fairness.
None of these points are necessarily a limitation; only certain uses
may have them.