fix missing_doc lint on private traits

Fixes #10069.
Stop propagating link arguments across crates

This is a fairly brittle modle that doesn't scale well across many crates. It's
unlikely that all of the downstream crates will have all of the original native
dependencies of all the upstream crates. In the case that FFI functions are
reachable, then it should be the responsibility of the downstream crate to link
against the correct library, or the upstream crate should prevent the functions
from being reachable.
Statically link sundown to librustdoc

Closes #10103
auto merge of #10217 : alexcrichton/rust/less-reachable, r=pcwalton

Previously, all functions called by a reachable function were considered
reachable, but this is only the case if the original function was possibly
inlineable (if it's type generic or #[inline]-flagged).
auto merge of #10165 : dcrewi/rust/missing-doc-on-private-trait, r=cmr

Fixes #10069.
Updated debugging metadata for ty_nil and ty_bot

ty_nil will now report as "()" in gdb
ty_bot will now report as "!" in gdb

Added test to confirm basic types debugging metadata.

This fixes #9226
auto merge of #10235 : mletterle/rust/issue-9226, r=jdm

ty_nil will now report as "()" in gdb
ty_bot will now report as "!" in gdb

Added test to confirm basic types debugging metadata.

This fixes #9226
Statically link libuv to librustuv

Similarly to the previous commit, libuv is only used by this library, so there's
no need for it to be linked into librustrt and available to all crates by
default.
auto merge of #10199 : alexcrichton/rust/no-propagate, r=brson

This commit removes the propagation of `link_args` attributes across crates. The first commit message has the reasons as to why. Additionally, this starts statically linking some C/C++ helper libraries that we have to their respective crates instead of throwing then in librustrt and then having everything depend on librustrt.

The major downside of this movement is that we're losing the ability to control visible symbols. I couldn't figure out a way to internalize symbols from a static library during the linking process, so everyone who links to librustdoc will be able to use its sundown implementation (not exactly ideal). I'm not entirely sure how to fix this (beyond generating a list of all public symbols, including rust ones, and passing that to the linker), but we may have a much easier time with this once we start using llvm's linker toolchain.

There's certainly a lot more possibilities in where this can go, but I didn't want to go too deep just yet. The main idea here is to stop propagating linker arguments and then see how we're able to start statically linking libraries as a result.

r? @catamorphism, you're going to be working on linking soon, so feel free to completely throw this away for something else!
Move rt::io traits into the prelude

These traits belong here, and were simply waiting for the std::io traits to get
removed. It's time they take their rightful positions!
Modify IoFactory's fs_mkdir, and add fs_rename

The invocation for making a directory should be able to specify a mode to make
the directory with (instead of defaulting to one particular mode). Additionally,
libuv and various OSes implement efficient versions of renaming files, so this
operation is exposed as an IoFactory call.
Remove all blocking std::os blocking functions

This commit moves all thread-blocking I/O functions from the std::os module.
Their replacements can be found in either std::rt::io::file or in a hidden
"old_os" module inside of native::file. I didn't want to outright delete these
functions because they have a lot of special casing learned over time for each
OS/platform, and I imagine that these will someday get integrated into a
blocking implementation of IoFactory. For now, they're moved to a private module
to prevent bitrot and still have tests to ensure that they work.

I've also expanded the extensions to a few more methods defined on Path, most of
which were previously defined in std::os but now have non-thread-blocking
implementations as part of using the current IoFactory.

The api of io::file is in flux, but I plan on changing it in the next commit as
well.

Closes #10057
Fill out the remaining functionality in io::file

This adds bindings to the remaining functions provided by libuv, all of which
are useful operations on files which need to get exposed somehow.

Some highlights:

* Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type
* Moved all file-related methods to be static methods under `File`
* All directory related methods are still top-level functions
* Created `io::FilePermission` types (backed by u32) that are what you'd expect
* Created `io::FileType` and refactored `FileStat` to use FileType and
  FilePermission
* Removed the expanding matrix of `FileMode` operations. The mode of reading a
  file will not have the O_CREAT flag, but a write mode will always have the
  O_CREAT flag.

Closes #10130
Closes #10131
Closes #10121
Move io::file to io::fs and fns out of File

This renames the `file` module to `fs` because that more accurately describes
its current purpose (manipulating the filesystem, not just files).

Additionally, this adds an UnstableFileStat structure as a nested structure of
FileStat to signify that the fields should not be depended on. The structure is
currently flagged with #[unstable], but it's unlikely that it has much meaning.