`Sample` iterator adaptor that randomly skips values and yields them later

This is on a branch separate from #21.

Adds a `Sample` iterator adaptor and a `SampleIterator<T>: Iterator<T>` adaptor trait with a default impl.

The `Sample` iterator uses a user-chosen PRNG (defaults to `TaskRng`) to randomly sample elements from an iterator based on a weighted boolean (configurable), while also holding skipped elements in a ringbuffer to yield later, so that it never discards elements.

If it skips an element, it pops from the back of the ringbuffer and yields that. If the ringbuffer is empty, it pushes the current element and recurses.

Once the underlying iterator is exhausted, it yields skipped elements in FIFO order. This could be randomized as well but would increase the recursion depth and make for more frequent sampling of the PRNG.

With finite iterators, it yields all elements in a random order, effectively shuffling the source collection. 
With infinite iterators, it skips or yields elements at random, storing skipped elements to possibly yield later but never discarding them.

Since the weight is a public field, the adaptor can later be set to yield just skipped elements, or directly from the underlying iterator.

**Bikeshedding:** Should the iterator be called `SkipRand` or `Shuffle` instead? I couldn't decide. Each of them implies different but somewhat intersecting behavior.

It might be a good idea to add a disclaimer that this hasn't been audited for cryptographic uses; I can't think of any ways that this would be useful in crypto but you never know. 

Theoretically, it shouldn't be predictable as long as the underling PRNG is cryptographically secure, though once the underlying iterator has been exhausted it will yield skipped elements in FIFO order which might be a potential security issue.

I guess it could use a second weighted boolean to decide whether or not to push the popped element back to front of the ringbuffer and recurse, but that would increase recursion depth and the additional randomness might be negligible, or even make it easier to predict.
When the None branch is just () or {} it's best to use if let since it's one less level of nesting.