libstd: Refactor Duration.

This changes the internal representation of `Duration` from

    days: i32,
    secs: i32,
    nanos: u32

to

    secs: i64,
    nanos: i32

This resolves #16466. Some methods now take `i64` instead of `i32` due
to the increased range. Some methods, like `num_milliseconds`, now
return an `Option<i64>` instead of `i64`, because the range of
`Duration` is now larger than e.g. 2^63 milliseconds.
libstd: Limit Duration range to i64 milliseconds.

This enables `num_milliseconds` to return an `i64` again instead of
`Option<i64>`, because it is guaranteed not to overflow.

The Duration range is now rougly 300e6 years (positive and negative),
whereas it was 300e9 years previously. To put these numbers in
perspective, 300e9 years is about 21 times the age of the universe
(according to Wolfram|Alpha). 300e6 years is about 1/15 of the age of
the earth (according to Wolfram|Alpha).
libcollections: In tests, remove some uses of deprecated methods and
unused imports.
add missing ! char to feature gate hint
Allow a regex filter for RUST_LOG

When specifying RUST_LOG, the programmer may append `/regex` to the end of the spec. All results will then be filtered using that regex.
Implement generalized object and type parameter bounds (Fixes #16462)
auto merge of #16453 : nikomatsakis/rust/type-bounds-3, r=pcwalton

Implements https://github.com/rust-lang/rfcs/pull/192.

In particular:

1. type parameters can have lifetime bounds and objects can close over borrowed values, presuming that they have suitable bounds.
2. objects must have a bound, though it may be derived from the trait itself or from a `Send` bound.
3. all types must be well-formed.
4. type parameters and lifetime parameters may themselves have lifetimes as bounds. Something like `T:'a` means "the type T outlives 'a`" and something like `'a:'b`" means "'a outlives 'b". Outlives here means "all borrowed data has a lifetime at least as long".

This is a [breaking-change]. The most common things you have to fix after this change are:

1. Introduce lifetime bounds onto type parameters if your type (directly or indirectly) contains a reference. Thus a struct like `struct Ref<'a, T> { x: &'a T }` would be changed to `struct Ref<'a, T:'a> { x: &'a T }`.
2. Introduce lifetime bounds onto lifetime parameters if your type contains a double reference. Thus a type like `struct RefWrapper<'a, 'b> { r: &'a Ref<'b, int> }` (where `Ref` is defined as before) would need to be changed to `struct RefWrapper<'a, 'b:'a> { ... }`.
2. Explicitly give object lifetimes in structure definitions. Most commonly, this means changing something like `Box<Reader>` to `Box<Reader+'static>`, so as to indicate that this is a reader without any borrowed data. (Note: you may wish to just change to `Box<Reader+Send>` while you're at it; it's a more restrictive type, technically, but means you can send the reader between threads.)

The intuition for points 1 and 2 is that a reference must never outlive its referent (the thing it points at). Therefore, if you have a type `&'a T`, we must know that `T` (whatever it is) outlives `'a`. And so on.

Closes #5723.
stabilize core::option

Per API meeting

  https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md

Most of the module is marked as stable or unstable; most of the unstable
items are awaiting resolution of conventions issues.

However, a few methods have been deprecated, either due to lack of use
or redundancy:

* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer
  for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator`
  impl.

Due to deprecations, this is a:

[breaking-change]
Fallout from stabilizing core::option
stabilize core::result

Per API meeting

  https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md

Most of the module is marked as stable or unstable; most of the unstable
items are awaiting resolution of conventions issues.

* `collect`: this functionality is being moved to a new `FromIterator`
  impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including
  `iter`, `as_slice`, and variants.

Due to deprecations, this is a:

[breaking-change]
auto merge of #16553 : nick29581/rust/log, r=huon

When specifying RUST_LOG, the programmer may append `/regex` to the end of the spec. All results will then be filtered using that regex.

r?
libstd: Wrap duration.rs at 100 characters.
auto merge of #16626 : ruud-v-a/rust/duration-reform, r=brson

This changes the internal representation of `Duration` from

    days: i32,
    secs: i32,
    nanos: u32

to

    secs: i64,
    nanos: i32

This resolves #16466. Note that `nanos` is an `i32` and not `u32` as suggested, because `i32` is easier to deal with, and it is not exposed anyway. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds.

A few remarks:
- Negating `MIN` is impossible. I chose to return `MAX` as `-MIN`, but it is one nanosecond less than the actual negation. Is this the desired behaviour?
- In `std::io::timer`, some functions accept a `Duration`, which is internally converted into a number of milliseconds. However, the range of `Duration` is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?
- Negative durations are not formatted correctly, but they were not formatted correctly before either.
auto merge of #16664 : aturon/rust/stabilize-option-result, r=alexcrichton

Per API meeting

  https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md

# Changes to `core::option`

Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.

However, a few methods have been deprecated, either due to lack of use or redundancy:

* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator` impl.

# Changes to `core::result`

Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.

* `collect`: this functionality is being moved to a new `FromIterator` impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants.

Due to deprecations, this is a:

[breaking-change]
auto merge of #16768 : nham/rust/libcollections_test_cleanup, r=alexcrichton

unused imports.

This is mostly converting uses of `push_back`, `pop_back`, `shift` and `unshift` to `push`, `pop`, `remove` and `insert`.
auto merge of #16770 : cburgdorf/rust/patch_overloaded_calls_hint, r=alexcrichton
Mention type of `for` exprs that don't implement Iterator.

This improves the error message by telling the user the exact type of
`x` if it doesn't implement `Iterator` in `for ... in x {}`.

Closes #16043.
Avoid flow-on Iterator error for `for ... in [ty err] {}`.

This squashes the

> `for` loop expression has type `[type error]` which does not implement
> the `Iterator` trait

message that one received when writing `for ... in x` where was
previously found to have a type error.

Fixes #16042.
Don't double free embedded, unsized slices

Thanks to @eddyb for finding the bug.

Closes #16826 (I hope)
auto merge of #16762 : huonw/rust/for-error-nice, r=alexcrichton

- print the type of `x` in `for ... in x` in the "does not implement Iterator" message
- avoid printing that message if `x` has a type error