This adds a new `#[cfg]` matcher against the `target_env` property of the
destination target triple. For example all windows triples today end with `-gnu`
but we will also hopefully support non-`gnu` targets for Windows, at which point
we'll need to differentiate between the two. This new `target_env` matches is
provided and filled in with the target's environment name.

Currently the only non-empty value of this name is `gnu`, but `musl` will be
shortly added for the linux triples.

This commit adds support to the makefiles, configuration script, and build
system to understand MUSL. This is broken up into a few parts:

* Any target of the form `*-musl` requires the `--musl-root` option to
  `./configure` which will indicate the root of the MUSL installation. It is
  also expected that there is a libunwind build inside of that installation
  built against that MUSL.

* Objects from MUSL are copied into the build tree for Rust to be statically
  linked into the appropriate Rust library.

* Objects for binary startup and shutdown are included in each Rust installation
  by default for MUSL. This requires MUSL to only be installed on the machine
  compiling rust. Only a linker will be necessary for compiling against MUSL on
  a target machine.

Eventually a MUSL and/or libunwind build may be integrated by default into the
build but for now they are just always assumed to exist externally.

This commit adds support for x86_64-unknown-linux-musl as a target of the
compiler. There's some comments in the commit about some of the more flavorful
flags passed to the linker as it's not quite as trivial as the normal specs.

MUSL for example provides its own start/end objects in place of the standard
ones shipped by gcc.

This commit modifies the standard library and its dependencies to link correctly
when built against MUSL. This primarily ensures that the right libraries are
linked against and when they're linked against they're linked against
statically.

MUSL support is currently only with static builds, so building a dylib will
always fail.

Statically linked executables do not succeed (aka MUSL-based executables).

Add the ability to ignore a test based on the environment of the triple being
used.

There were a few test cases to fix:

* Dynamic libraries are not supported with MUSL right now, so all of those
  related test which force or require dylibs are ignored.
* Looks like the default stack for MUSL is smaller than glibc, so a few stack
  allocations in benchmarks were boxed up (shouldn't have a perf impact).
* Some small linkage tweaks here and there
* Out-of-stack detection does not currently work with MUSL