Allow getting an arbitrary length with a maximum upper bound

[fitzgen]

Sometimes you don't want more than N things generated because, for example, it makes the fuzz target too slow and run up against libfuzzer timeouts.

A solution to this is pretty similar to a solution to #35 in that they both want access to (or something closer to) the underlying int_in_range from the end of the byte string.

impl Unstructured<'_> {
    pub fn arbitrary_len_with_max<ElementType>(&mut self, max: usize) -> Result<usize>
    where
        ElementType: Arbitrary,
    {
        ...
    }
}

[gkelly]

I was thinking about this today. With the way that arbitrary_iter works you end up flipping a coin to determine if you produce another element, so the distribution of lengths for Vec is biased to short values.

I was thinking of the following: adding an #[arbitrary(min_len = X, max_len = X)] attribute to the derive_arbitrary proc macro that would choose a length from the unstructured source (presumably just like lengths currently are), and then write something like AribitraryTakeIter that keeps taking Ts from the unstructured source until it hits the limit or the source runs out. This would mean that if the unstructured has enough bits that you'd get a populated Vec in the (min_len, max_len) range, but if it runs out early you just end up with a truncated Vec potentially shorter than you wanted. Maybe min_len is too strong a name. 😅

This addresses the "I want at most N things" case (you set max_len) and the "I want at least N things" case. I understand that this now makes the arbitrary impl for a Vec much hungrier for data if it has these attributes, but it won't affect values which don't opt-in to these limits.