stabilize more of collections

This stabilizes most of libcollections, carefully avoiding sections of API which are being managed in other PRs. APIs which are not stable are marked explicitly unstable with a reason. Also deprecates the following:

* DList
  * rotate_forward
  * rotate_backward
  * prepend
  * insert_when
  * insert_ordered
  * merge

* VecMap
  * update
  * update_with_key

as such this is a

[breaking-change]
I do understand the worry about confusion when a type "silently" takes a
lifetime parameter, but this is why we have ensured it's very easy to
determine whether a type does: it's explicit in the definition. (Other
options would allow it to be implicit even there, but that seemed truly
problematic.) My feeling is that, just as you learn that & takes a
lifetime, you come to learn this about other types in play. It's similar to
knowing whether a type is Copy or not -- it's a very fundamental aspect of
the type. So I personally have no problem eliding in these cases.

As @huonw notes, though, what shows up in rustdoc should probably be more
uniform/independent of these concerns.

On Tue, Dec 30, 2014 at 6:34 PM, Alex Crichton <notifications@github.com>
wrote:

> In src/libcollections/bit.rs
> <https://github.com/rust-lang/rust/pull/20356#discussion-diff-22373132>:
>
> > @@ -578,7 +579,7 @@ impl Bitv {
> >      /// assert_eq!(bv.iter().filter(|x| *x).count(), 7);
> >      /// ```
> >      #[inline]
> > -    #[unstable = "matches collection reform specification, waiting for dust to settle"]
> > +    #[stable]
> >      pub fn iter<'a>(&'a self) -> Bits<'a> {
>
> I've generally been removing them for strings (and I think @aturon
> <https://github.com/aturon> has as well for vectors), so we should
> probably be consistent at the very least. I understand low level code
> wanting to avoid elision, but I'm not sure I buy the "without elision it's
> more clear" case because that's largely the purpose of elision (to move the
> lifetimes out of the way of what's going on).
>
> For all these higher-level apis for collections I would personally elide
> as much as possible, but I'm curious what @aturon
> <https://github.com/aturon> thinks
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rust-lang/rust/pull/20356/files#r22373132>.
>