Use macro-generated impls even for foreign types

[kpreid]

Make a macro that can be used to generate an implementation for another crate's type just like the derive macro does for a local one, and use it to implement Exhaust for types like Option, Result and Ordering.

This will ensure that our impls can have all the expected functionality and be tidily opaque rather than an aggregation of iterator combinators.

Open question: Should we rigorously use such implementations, or keep using iter::once, iter::empty, and such for simple cases?

[kpreid]

Another possibility would be to wait for Rust to stabilize RFC 2515 type_alias_impl_trait, at which point we can just use

impl Exhaust for SomeType {
    type Target = impl Iterator<Item = SomeType>;
    ...
}

for every impl Exhaust that isn't intending to expose its iterator type.

[kpreid]

#33 did a little bit of this, for Result and Option.

[kpreid]

Reviewing the current state, there aren't actually any remaining big piles of iterator adapters after #33. Most of the exposed types are delegations to another Exhaust implementation’s iterator. Notable exceptions are:

• io::Cursor (the one use of FlatZipMap)
• impl_singleton!s (but when singletonhood is a public fact about a type, exposing the iterator type as Once seems fine)
• impl_via_array!s
• impl_via_range!s

Therefore, I think the reasonable thing to do might be to add wrapper type generation to impl_via_array and impl_via_range, and call this sufficiently addressed. In the long run (before or after 1.0? who knows), we’ll want to consider switching to TAIT or even RPIT to make the types truly opaque.