RFC: Added an FindIterator to str

[Kimundi]

This implements an FindIterator with .find_iter() and .find_rev_iter() on string slices that works like .find() and .rfind(), but returns all matches instead of just the first one.

This touches upon a few other design questions I'm having of the string library:

• In Cleaned up str module a bit #9392, I'm trying to normalize the names for operations that operate starting from the back to _rev, which has met some resistance. This PR would allow removing at least find() and rfind() completely and replace them with this Iterator.
• If we drop the reverse iterator constructors (DoubleEndedIterators already offer an method for inverting them), we'd also remove a lot of repetition and the _rev suffix completly - see Should the reverse iterators on strings and vectors be removed? #9391.
• The resulting "foo".find_iter('o').nth(0) and "foo".find_iter('f').invert().nth(0) would become quite long though, which touches on Consider removing the _iter suffixes on specialized Iterator constructors #9440.

---

Also as part of this PR I'm moving str::CharEq to char::CharEq, introduce a new trait ToChar, and implement them both for ascii::Ascii.

I'm doing the movement of CharEq because it seems to me that even though it's being intended to be used by string functions, the actual trait encapsulates something relevant for chars in general. And str.rs needs any chance it can get to become shorter. ;)

The ToChar trait is necessary for the implementation of FindIterator to not include two almost identical copies of the same function in both next() and next_back()

[pnkfelix]

My gut tells me that we might want to generalize this API to find substrings in a string, rather than individual characters.

(I'd suggest regexps, but it doesn't seem right to shove them into str.rs.)

[alexcrichton]

Closing due to lack of activity, but feel free to reopen with an updated version!