ScanIterator, and to_vec/foldl iterator consumers

[huonw]

@thestinger r?

The 2 _unlimited functions are marked unsafe since they may not terminate.

The state fields of the Unfoldr and Scan iterators are public, since being able to access the final state after the iteration has finished seems reasonable/possibly useful.

Lastly, I converted the tests to use .to_vec, which halves the amount of code for them, but it means that a .transform(|x| *x) call is required on each iterator.

(removed the 2 commits with to_vec and foldl.)

[huonw]

(Also, if any of my iterator contributions go against your plan for them, feel free to say no and/or cherry-pick and fiddle with them.)

[Thiez]

I'm not sure we really need the the division between limited and unlimited versions. After applying a few filters and chains one may end up with an iterator of unknown length that is nevertheless guaranteed to be finite. Should one call foldl with UINT_MAX or resort to 'unsafe' code (which does not actually perform any unsafe operation)?
I propose making the '_unlimited' methods the default and remove their unsafety. People who wish to use some limit can use .take(limit) before invoking foldl/to_vec.

It seems to me that the comment on 'to_vec_unlimited' is incorrect, it suggests that it may never terminate but is in fact guaranteed to do so when your program runs out of memory.

[huonw]

@Thiez I was going for safety by default, so that programs can tell the compiler "trust me, I know this is finite" with unsafe, but in other cases, there is a hard limit on the program exploding. I can see the advantage of not doing this however, and the names/documentation could make this clearer.

The to_vec_unlimited documentation point is fairly pedantic, but I'll change it.

(However, it looks like foldl and to_vec may not be landed in this patch anyway, due to IRC discussions.)