add prop_rng_map<T>(Fn(r: Rng, T) method

[vitiral]

This relates to #13, and could probably be a way to just solve it outright.

The idea is that you would do:

impl_strategy
    .prop_rng_map(|rng, value| {
        // compose new value using the rng
    }

As far as I can tell, there is no way to get the Rng object in a mapped body. This is certainly a power feature, but in some case (like sampling) there is no reason why a simple Rng object is not sufficient -- no shrinking, etc could be gained anyway.

Obviously this could be misused to effectively make shrinking impossible and complicate a Strategy chain, so this feature may not be desired. However, I think it would help provide at least a workaround for any issue that a developer wants to address, even if the solution isn't 100% in compliance with this library.

[AltSysrq]

So I actually added this in 0.3.2 as prop_perturb(). While the original need here has been addressed via #13, I do think it provides a useful "escape hatch" in the future as less powerful versions of those two could be implemented on top of it, for example.

It also turns out that this doesn't break shrinking as long as the user function gets the same Rng each time, which the new combinator ensures.

[vitiral]

Awesome, prop_perturb is exactly what I wanted!

In fact, I've come to realize that my needs are far more complicated than simple sampling, so this is what I need anyway. I've been using thread_rng waiting for these features, but now I can refactor and make it deterministically random (and probably faster). Yay!