Port modules "str" and "vec" to interface "iter"

[kud1ing]

"iter" is now in core: 303e48e

• Implement the "iter" interface for "str" and "vec".
• Functions like str::any, vec::all etc. should be moved to "iter", so that the functionality has only one implementation in "iter".
• Remove now unnecessary function definitions in "str" and "vec".

Also we could have only functions which iterate.
E.g. if we only provide str::chars_iter, we could get rid of str::chars, since this can be easily implemented using iter::to_list and str::chars_iter.

See https://mail.mozilla.org/pipermail/rust-dev/2012-January/001216.html

[marijnh]

I think shorthands like str::chars have their place, even if they can be implemented by combining other functions. They are likely to be more efficient, and less awkward to write.

[kud1ing]

Yes, maybe. At least their implementation could be replaced.

[nikomatsakis]

I guess the question is which will be used more often, the version that returns a vector or the version that returns an iterator. We only really need one anyhow as a vector is "iterable" in the iter module.

[nikomatsakis]

(Though of course it's more efficient not to construct an intermediate vector)

[db48x]

I took a look at this today, but I don't see how you would define an all method for the fn@(fn(A)) types, because that doesn't return a bool. Are there any examples where this implementation gets used? It seems like an obscure thing to do.

[catamorphism]

I believe this is done (core::iter has impls of iterable for str and [A].)