Upgrade libuv to the current master + our patches

There were two main differences with the old libuv and the master version:

1. The uv_last_error function is now gone. The error code returned by each
   function is the "last error" so now a UvError is just a wrapper around a
   c_int.
2. The repo no longer includes a makefile, and the build system has change.
   According to the build directions on joyent/libuv, this now downloads a `gyp`
   program into the `libuv/build` directory and builds using that. This
   shouldn't add any dependences on autotools or anything like that.

Closes #8407
Closes #6567
Closes #6315
Implement process bindings to libuv

Closes #6436
auto merge of #8645 : alexcrichton/rust/issue-6436-run-non-blocking, r=brson

This overhauls `std::run` to instead run on top of libuv. This is *not* in a mergeable state, I've been attempting to diagnose failures in the compiletest suite. I've managed to find a fair number of bugs so far, but I still  don't seem to be done yet.

Notable changes:
* This requires upgrading libuv. From the discussion on #6567, I took libuv master from a few days ago, applied one patch to fix process spawning with multiple event loops in libuv, and pushed to my own fork
* The build system for libuv has changed since we last used it. There's some extra checkout from a google build system which apparently does all the magic if you don't want to require autotools, and the google system just requires python. I updated the Makefile to get this build system and build libuv with it instead. This is untested on windows and arm, and both will probably need to see some improvement.
* This required adding some pipe bindings to libuv as well. Currently the support is pretty simple and probably completely unsafe for pipes, but you at least get read/write methods. This is necessary for capturing output of processes.
* I didn't redesign `std::run` at all, I simply tried to reimplement all the existing functionality on top of libuv. Some functions ended up dying, but nothing major. All uses of `std::run` in the compiler still work just fine.

I'm not quite sure how the rest of the runtime deals with this, but I marked process structures as `no_send` because the waiting/waking up has to happen in the same event loop right now. If processes start migrating between event loops then very bad things can happen. This may be what threadsafe I/O would fix, and I would be more than willing to rebase on that if it lands first.

Anyway, for now I wanted to put this up for review, I'm still investigating the corruption/deadlock bugs, but this is in an *almost* workable state. Once I find the bugs I'll also rebase on the current master.