Get rid of the iter-trait hack

[msullivan]

The iter-trait hack is really frumious. We have better ways to do it.

[msullivan]

Argh. I refactored it to use another impl parameterized over anything implementing base_iter, but now type inference fails in a bunch of places with the type of this value must be known in this context errors.

[msullivan]

I've fixed all of the bugs I thought were blocking this, and have been left with more fundamental issues.

I was trying to solve this by making an impl of ExtendedIter for all instances of BaseIter:

impl<A, I: BaseIter<A>> I: iter::ExtendedIter<A> {
...
}

This now sort of works. There are some big downsides, though, that all stem from the fact that all calls of methods in ExtendedIter will immediately resolve to this impl. This means that autoderef and implicit borrows won't work when calling these methods, since the original type will match, and it also means that no other trait or impl can use method names that are also used by ExtendedIter, since there will be multiple matching methods.

So I'm not going to finish fixing the things it breaks. I'm going to unassign myself.

The right way to get rid of this is going to be using default implementations as tracked in #2794.

[catamorphism]

I tried fixing this bug, but I believe it's blocked on #3979:

pub trait ExtendedIter<A>: BaseIter<A> {
    pure fn eachi(blk: fn(uint, v: &A) -> bool) {
        eachi(&self, blk)
    }
   // etc.

(added to core::iter)

and I got:

iter.rs:32:8: 32:13 error: failed to find an implementation of trait @iter::BaseIter<<V2>> for <V3>
/Users/tchevalier/rust/src/libcore/iter.rs:32         eachi(&self, blk)

This resembles the behavior in #3979.

Bumping to 0.6

[catamorphism]

Now that I have a fix for #3979, I'm working on this.

[brson]

The last time I tried I hit #4148

[catamorphism]

Oh, yeah, I think I hit #4148 as well. I didn't realize at first what the issue was and now it's looking pretty intimidating.