Only run dsymutil on OSX in debug builds

When there are no debug symbols generated, then the program just prints an
annoying warning otherwise.

Closes #10198
Add a flag to force generating toplevel crate map

As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.

This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
Optimize creation of buffered readers/writers

I was benchmarking rust-http recently, and I saw that 50% of its time was spent
creating buffered readers/writers. Albeit rust-http wasn't using
std::rt::io::buffered, but the same idea applies here. It's much cheaper to
malloc a large region and not initialize it than to set it all to 0. Buffered
readers/writers never use uninitialized data, and their internal buffers are
encapsulated, so any usage of uninitialized slots are an implementation bug in
the readers/writers.
Removed test issue-912.rs

This was marked xfail-test
According to rust's issue #912, this will not be fixed.
There's no point in keeping the test if it is never intended to pass.
Remove run-pass/issue-3907-2.rs

This test is not supposed to compile; there is an equivalent test in compile-fail/issue-3907.rs.
Remove test issue-3461

According to issue #3461, it doesn't sound like this is planned to be fixed.
auto merge of #10422 : alexcrichton/rust/explicit-crate-map, r=pcwalton

As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.

This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
Implemented a ProcessExit enum and helper methods to std::rt::io::process for getting process termination status, or the signal that terminated a process.

A test has been added to rtio-processes.rs to ensure signal termination is picked up correctly.
Update docs for Fractional, Algebraic, Round, and Trigonometric traits.
Add docs for traits Exponential, Hyperbolic, BitCount.
Got directions backwards in to_degrees and to_radians docs.
auto merge of #10109 : pcmattman/rust/pass-nonzero-exit-status-on-termination-by-signal, r=alexcrichton

The UvProcess exit callback is called with a zero exit status and non-zero termination signal when a child is terminated by a signal.

If a parent checks only the exit status (for example, only checks the return value from `wait()`), it may believe the process completed successfully when it actually failed.

Helpers for common use-cases are in `std::rt::io::process`.

Should resolve https://github.com/mozilla/rust/issues/10062.
auto merge of #10424 : alexcrichton/rust/optimize-buffered, r=brson

I was benchmarking rust-http recently, and I saw that 50% of its time was spent
creating buffered readers/writers. Albeit rust-http wasn't using
std::rt::io::buffered, but the same idea applies here. It's much cheaper to
malloc a large region and not initialize it than to set it all to 0. Buffered
readers/writers never use uninitialized data, and their internal buffers are
encapsulated, so any usage of uninitialized slots are an implementation bug in
the readers/writers.
Use constants instead of raw values.
auto merge of #10425 : astrieanna/rust/rm-issue-912, r=brson

According to rust's issue #912, this will not be fixed. There's no point in keeping the test if it is never intended to pass.
auto merge of #10198 : alexcrichton/rust/darwin-quiet, r=jdm

Instead of running dsymutil for all builds, this changes it to only run the program for debug builds.

Closes #3495
auto merge of #10435 : jayanderson/rust/docs, r=huonw

This fills in some missing docs in the nums package. Let me know if this is on the right track for what's wanted for docs. I can probably fill in more in the future. Thanks.

(As a side note the precedence of the unary negative operator '-' tripped me up for a bit. Essentially I would expect `-25.0f32.sqrt()` to result in NaN instead of `-5.0`.)