As with the previous commit with `librand`, this commit shuffles around some
`collections` code. The new state of the world is similar to that of librand:

* The libcollections crate now only depends on libcore and liballoc.
* The standard library has a new module, `std::collections`. All functionality
  of libcollections is reexported through this module.

I would like to stress that this change is purely cosmetic. There are very few
alterations to these primitives.

There are a number of notable points about the new organization:

* std::{str, slice, string, vec} all moved to libcollections. There is no reason
  that these primitives shouldn't be necessarily usable in a freestanding
  context that has allocation. These are all reexported in their usual places in
  the standard library.

* The `hashmap`, and transitively the `lru_cache`, modules no longer reside in
  `libcollections`, but rather in libstd. The reason for this is because the
  `HashMap::new` contructor requires access to the OSRng for initially seeding
  the hash map. Beyond this requirement, there is no reason that the hashmap
  could not move to libcollections.

  I do, however, have a plan to move the hash map to the collections module. The
  `HashMap::new` function could be altered to require that the `H` hasher
  parameter ascribe to the `Default` trait, allowing the entire `hashmap` module
  to live in libcollections. The key idea would be that the default hasher would
  be different in libstd. Something along the lines of:

      // src/libstd/collections/mod.rs

      pub type HashMap<K, V, H = RandomizedSipHasher> =
            core_collections::HashMap<K, V, H>;

  This is not possible today because you cannot invoke static methods through
  type aliases. If we modified the compiler, however, to allow invocation of
  static methods through type aliases, then this type definition would
  essentially be switching the default hasher from `SipHasher` in libcollections
  to a libstd-defined `RandomizedSipHasher` type. This type's `Default`
  implementation would randomly seed the `SipHasher` instance, and otherwise
  perform the same as `SipHasher`.

  This future state doesn't seem incredibly far off, but until that time comes,
  the hashmap module will live in libstd to not compromise on functionality.

* In preparation for the hashmap moving to libcollections, the `hash` module has
  moved from libstd to libcollections. A previously snapshotted commit enables a
  distinct `Writer` trait to live in the `hash` module which `Hash`
  implementations are now parameterized over.

  Due to using a custom trait, the `SipHasher` implementation has lost its
  specialized methods for writing integers. These can be re-added
  backwards-compatibly in the future via default methods if necessary, but the
  FNV hashing should satisfy much of the need for speedier hashing.

A list of breaking changes:

* HashMap::{get, get_mut} no longer fails with the key formatted into the error
  message with `{:?}`, instead, a generic message is printed. With backtraces,
  it should still be not-too-hard to track down errors.

* The HashMap, HashSet, and LruCache types are now available through
  std::collections instead of the collections crate.

* Manual implementations of hash should be parameterized over `hash::Writer`
  instead of just `Writer`.

[breaking-change]

An interface that gives a better control over the load factor and the minimum capacity for HashMap.
The size of `HashMap<K, V>` is now 64 bytes by default on a 64-bit platform (or at least 40 bytes, that is 3 words less, with FNV and without minimum capacity)

Unanswered questions about `ResizePolicy`

* should it control the `INITIAL_CAPACITY`?
* should it fully control the resizing behavior? Even though the capacity always changes by a factor of 2.
* is caching `grow_at` desirable?

special thanks to @EddyB and @pnkfelix

A few notable improvements were implemented to cut down on the number of aborts
triggered by the standard library when a local task is not found.

* Primarily, the unwinding functionality was restructured to support an unsafe
  top-level function, `try`. This function invokes a closure, capturing any
  failure which occurs inside of it. The purpose of this function is to be as
  lightweight of a "try block" as possible for rust, intended for use when the
  runtime is difficult to set up.

  This function is *not* meant to be used by normal rust code, nor should it be
  consider for use with normal rust code.

* When invoking spawn(), a `fail!()` is triggered rather than an abort.

* When invoking LocalIo::borrow(), which is transitively called by all I/O
  constructors, None is returned rather than aborting to indicate that there is
  no local I/O implementation.

A test case was also added showing the variety of things that you can do without
a runtime or task set up now. In general, this is just a refactoring to abort
less quickly in the standard library when a local task is not found.

The contents of a `RingBuf` are shown in the same way as the contents of a `Vector`. See the tests for examples.

Previously, documentation for an inlined trait (i.e. a trait imported
and reexported from another crate) didn't display the trait's supertraits.

Closes #14636

Previously, documentation for an inlined trait (i.e. a trait imported
and reexported from another crate) didn't display the trait's
supertraits.

Closes #14636

This PR adds two features to make it possible to transform an `Iterator<u8>` into a `Reader`. The first patch adds a method to mutable slices that allows it to be updated with an `Iterator<T>` without paying for the bounds cost. The second adds a Iterator adaptor, `IterReader`, to provide that `Reader` interface.

I had two questions. First, are these named the right things? Second, should `IterReader` instead wrap an `Iterator<Result<u8, E>>`? This would allow you to `IterReader::new(rdr.bytes())`, which could be useful if you want to apply some iterator transformations on a reader while still exporting the Reader interface, but I'd expect there'd be a lot of overhead annotating each byte with an error result.

These are a few assorted fixes for some issues I found this morning (details in the commits).

This commit removes the <M: Any + Send> type parameter from Option::expect in
favor of just taking a hard-coded `&str` argument. This allows this function to
move into libcore.

Previous code using strings with `expect` will continue to work, but code using
this implicitly to transmit task failure will need to unwrap manually with a
`match` statement.

[breaking-change]
Closes #14008

This time we're not promoting anything directly to 'stable', but instead promoting functions we're happy with to 'unstable'. They'll become stable in another pass later.

* null and mut_null are unstable. Their names may change if the unsafe
  pointer types change.
* copy_memory and copy_overlapping_memory are unstable. We think they
  aren't going to change.
* set_memory and zero_memory are experimental. Both the names and
  the semantics are under question.
* swap and replace are unstable and probably won't change.
* read is unstable, probably won't change
* read_and_zero is experimental. It's necessity is in doubt.
* mem::overwrite is now called ptr::write to match read and is
  unstable. mem::overwrite is now deprecated
* array_each, array_each_with_len, buf_len, and position are
  all deprecated because they use old style iteration and their
  utility is generally under question.

Note that `mem::overwrite`, which was just declared stable last week, is deprecated now in favor of `ptr::write`. Woo!

* null and mut_null are unstable. Their names may change if the unsafe
  pointer types change.
* copy_memory and copy_overlapping_memory are unstable. We think they
  aren't going to change.
* set_memory and zero_memory are experimental. Both the names and
  the semantics are under question.
* swap and replace are unstable and probably won't change.
* read is unstable, probably won't change
* read_and_zero is experimental. It's necessity is in doubt.
* mem::overwrite is now called ptr::write to match read and is
  unstable. mem::overwrite is now deprecated
* array_each, array_each_with_len, buf_len, and position are
  all deprecated because they use old style iteration and their
  utility is generally under question.

libc: only provide an rlib.

There's absolutely no reason for `libc` to be offered as a dynamic
library.

These are a pain to rebase, so I'm separating this from the rest of my work.
Nothing controversial here, just some simple refactoring and removal of an
unused entry in the token table. Brings the lexer into 2012 with methods!

A few notable improvements were implemented to cut down on the number of aborts
triggered by the standard library when a local task is not found.

* Primarily, the unwinding functionality was restructured to support an unsafe
  top-level function, `try`. This function invokes a closure, capturing any
  failure which occurs inside of it. The purpose of this function is to be as
  lightweight of a "try block" as possible for rust, intended for use when the
  runtime is difficult to set up.

  This function is *not* meant to be used by normal rust code, nor should it be
  consider for use with normal rust code.

* When invoking spawn(), a `fail!()` is triggered rather than an abort.

* When invoking LocalIo::borrow(), which is transitively called by all I/O
  constructors, None is returned rather than aborting to indicate that there is
  no local I/O implementation.

* Invoking get() on a TLD key will return None if no task is available

* Invoking replace() on a TLD key will fail if no task is available.

A test case was also added showing the variety of things that you can do without
a runtime or task set up now. In general, this is just a refactoring to abort
less quickly in the standard library when a local task is not found.

Unlike ImmutableClonableVector::permutations() which returns an iterator,
cloning the entire array each iteration, these methods mutate the vector in-place.
For that reason, these methods are much faster; between 35-55 times faster,
depending on the benchmark. They also generate permutations in lexicographical order.

Refactored the load factor and the minimum capacity out of HashMap.
The size of HashMap<K, V> is now 64 bytes by default on a 64-bit platform
(or 48 bytes, that is 2 words less, with FNV)
Added a documentation in a few places to clarify the behavior.

Fixes #13352

Show impl for Rc

There's absolutely no reason for `libc` to be offered as a dynamic
library.

An empty regex is a valid regex that always matches. This behavior
is consistent with at least Go and Python.

A couple regression tests are included.

I'd just assume that an empty regex is an invalid regex and that an error should be returned (I can't think of any reason to use an empty regex?), but it's probably better to be consistent with other regex libraries.

An empty regex is a valid regex that always matches. This behavior
is consistent with at least Go and Python.

A couple regression tests are included.

#14589.

The logical location for the documentation of a primitive is in the module that
declared it was a module for that primitive.

The distinction doesn't make sense any more since we don't have do blocks anymore.

This commit removes the <M: Any + Send> type parameter from Option::expect in
favor of just taking a hard-coded `&str` argument. This allows this function to
move into libcore.

Previous code using strings with `expect` will continue to work, but code using
this implicitly to transmit task failure will need to unwrap manually with a
`match` statement.

[breaking-change]
Closes #14008

Example URL in CrateId documentation is:

    `gihub.com/mozilla/rust`

Instead of:

    `github.com/mozilla/rust`

Also update libsyntax/crateid.rs licensing header for 2014.

As part of removing `pub use` glob, two extra import globs were
injected to make `quote_expr!` work. However the globs caused
`unused_import` warning in some places.

Quasiquoter needed the globs since it generated idents (e.g. `TyU`)
rather than absolute paths (`::syntax::ast::TyU`).
This patch removes the extra globs and makes quasiquoter use absolute
paths.

Fixes #14618

cc @sfackler

Let me know if the amount of tests is enough or too much.

Update licensing header for 2014.