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
simplify memcpy/memmove/memset intrinsics

This moves the per-architecture difference into the compiler.
auto merge of #10251 : thestinger/rust/ptr, r=alexcritchton

This moves the per-architecture difference into the compiler.
Ensure rustpkg test fails if tests failed

It previously set the exit status, but the main wrapper paved over that
with an exit code of 0.

Closes #9761
auto merge of #10254 : sfackler/rust/rustpkg-test-failure, r=alexcrichton

It previously set the exit status, but the main wrapper paved over that
with an exit code of 0.

Closes #9761
Fix the temporary name of the object file created

This file did not respect the #[link(name = "...")] attribute when it was
clearly intended to do so. The problem is that the crate attributes just weren't
passed in. This causes lots of problems in rust today because the object file
for all our libraries is inferred to be 'lib.o' because all of the files are
called 'lib.rs'.

I tried to figure out a good way to test for this, but I wasn't able to come up
with a good way that fit into our current testing framework. Nonetheless, I have
tested this locally and object files get named as they should. This should fix
compiling with `make -jN` again (because the object files are all different
again).
auto merge of #10260 : alexcrichton/rust/fix-temp-name, r=thestinger

This file did not respect the #[link(name = "...")] attribute when it was
clearly intended to do so. The problem is that the crate attributes just weren't
passed in. This causes lots of problems in rust today because the object file
for all our libraries is inferred to be 'lib.o' because all of the files are
called 'lib.rs'.

I tried to figure out a good way to test for this, but I wasn't able to come up
with a good way that fit into our current testing framework. Nonetheless, I have
tested this locally and object files get named as they should. This should fix
compiling with `make -jN` again (because the object files are all different
again).
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.

Closes #10241
auto merge of #10179 : alexcrichton/rust/rt-improvements, r=cmr

This fleshes out the io::file module a fair bit more, adding all of the functionality that I can think of that we would want. Some questions about the representation which I'm curious about:

* I modified `FileStat` to be a little less platform-agnostic, but it's still fairly platform-specific. I don't want to hide information that we have, but I don't want to depend on this information being available. One possible route is to have an `extra` field which has all this os-dependent stuff which is clearly documented as it should be avoided.

* Does it make sense for directory functions to be top-level functions instead of static methods? It seems silly to import `std::rt::io::file` and `std::rt::io::File` at the top of files that need to deal with directories and files.
Relax the constraints on a debuginfo test

The snapshot just failed due to a debuginfo test failing, and according to its
output at
http://buildbot.rust-lang.org/builders/snap3-linux/builds/564/steps/test/logs/stdio
it appears to be because the printed lines has a little less information than
the original lines were checking for. I would suspect that this is just because
of a slightly different version of gdb, but it's not that serious regardless.
auto merge of #10276 : alexcrichton/rust/fix-debug-info, r=jdm

The snapshot just failed due to a debuginfo test failing, and according to its
output at
http://buildbot.rust-lang.org/builders/snap3-linux/builds/564/steps/test/logs/stdio
it appears to be because the printed lines has a little less information than
the original lines were checking for. I would suspect that this is just because
of a slightly different version of gdb, but it's not that serious regardless.