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).
Always insert methods into the search index, even if we're currently in a private module.

Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.

Fixes issue #11943
libcollections: In tests, remove some uses of deprecated methods and
unused imports.
add missing ! char to feature gate hint
Add a simple test for rustdoc search index contents
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]
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
auto merge of #16838 : nick29581/rust/dst-bug-4, r=pnkfelix,nikomatsakis

Don't double free embedded, unsized slices.

Merge/rebase error from DST. Thanks to @eddyb for finding.

Closes #16826 (I hope)

r?
auto merge of #16767 : SiegeLord/rust/reexported_methods, r=cmr

Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.

Fixes issue #11943