libs: stabilize iter module

This is an initial pass at stabilizing the `iter` module. The module is
fairly large, but is also pretty polished, so most of the stabilization
leaves things as they are.

Some changes:

* Due to the new object safety rules, various traits needs to be split
  into object-safe traits and extension traits. This includes `Iterator`
  itself. While splitting up the traits adds some complexity, it will
  also increase flexbility: once we have automatic impls of `Trait` for
  trait objects over `Trait`, then things like the iterator adapters
  will all work with trait objects.

* In general, extension traits new and old are following an [in-progress
  convention](rust-lang/rfcs#445). As such, they are marked `unstable`.

* As usual, anything involving closures is `unstable` pending unboxed
  closures.

* A few of the more esoteric/underdeveloped iterator forms (like
  `RandomAccessIterator` and `MutableDoubleEndedIterator`, along with
  various unfolds) are left experimental for now.

* The `order` submodule is left `experimental` because it will hopefully
  be replaced by generalized comparison traits.

* "Leaf" iterators (like `Repeat` and `Counter`) are uniformly
  constructed by free fns at the module level. That's because the types
  are not otherwise of any significance (if we had `impl Trait`, you
  wouldn't want to define a type at all).

Closes #17701

Due to renamings and splitting of traits, this is a:

[breaking-change]

r? @alexcrichton 
The example I've seen before is along the lines of:

```rust
fn main() {
    let vec = vec![1, 2, 3, 4, 5];
    let mut iter = vec.into_iter().peekable(); // peekable makes no difference
    let a: Vec<int> = iter.by_ref().take_while(is_odd).collect(); // takes 1, drops 2
    let b: Vec<int> = iter.by_ref().take_while(is_even).collect(); // drops 3
    let c: Vec<int> = iter.by_ref().take_while(is_odd).collect();  // drops 4
    let rest: Vec<int> = iter.collect();
    println!("a={} b={} c={} rest={}", a, b, c, rest);
} // prints a=[1], b=[], c=[], rest=[5]

fn is_odd(&x: &int) -> bool { 
    x % 2 == 1
}

fn is_even(&x: &int) -> bool {
    x % 2 == 0
}
```

The problem here being that the methods like `skip_while` and `take_while` consume elements even though they in theory can preserve the elements of the underlying iterator if its peekable. Which is to say that `SkipWhile<Peekable<T>>` can actually not consume an element when the `SkipWhile` starts to return `None`, but it has to perform like `SkipWhile<T>` where it always consumes the element that returns `None`.

This may be a problem with `skip_while` or `take_while` as well, just wanted to make sure that these concerns were here.

I know that I've personally found it somewhat clunky to use. I generally only have an `Iterator<T>` instead of a `Peekable<Iterator<T>>` and then having to pass a `Peekable` all over the place is pretty painful. That's pretty fundamental though, and I'm not sure there's anything that we can do to alleviate my personal concern here.