Remove librustuv and dependencies

[aturon]

This PR begins the process of runtime removal by dismantling the librustuv crate and associated event loop.

The result is that, while libgreen can still be used for task scheduling purposes, it will no longer be feasible to use green-threaded I/O.

Removing the libuv-based event loop eases the transition away from the runtime system, which will be done incrementally.

In terms of visible API changes, this PR:

• Removes std::io::signal, which was never implemented on the native threading model.
• Removes the iotest! macro, which was previously used to run I/O tests on both green and native threading models.
• Removes the green_start! macro for starting an application with a librustuv event loop.
• Removes the librustuv crate itself.

It also removes the libuv and gyp submodules and adjusts the build system and copyright notices accordingly.

If you wish to continue using librustuv and green-threaded I/O, consider using green-rs, which provides its own I/O stack.

[aturon]

cc @alexcrichton, this is ready for an initial review but needs a bit more work to pass tests.

This PR replaces an older one that initially aimed to do this work. (@anchovieshat, I've been trying to reach you about this, but was unsuccessful.) This PR more thoroughly and conservatively addresses tests, as well as a few other details.

[aturon]

(Also note that the changes are broken into several commits to ease reviewing.)

[alexcrichton]

We don't currently have a migration path for users of librustuv, although I have worked on this out of tree. At this point, I think I should tidy that up so it works with the in-tree libgreen today, and move it to rust-lang. Does that sound ok? That way you can put in the commit message the migration path forward.

[aturon]

@alexcrichton My worry about that is that, in my main branch for the I/O work, I'm dismantling the rtio infrastructure and coupling std::io directly to the new platform_imp infrastructure instead. I'm hoping to start landing some of those changes in the near future. So I'm not sure how viable an rtio-based migration path is, even in the short term.

In the long term, the only way to keep green-threaded I/O alive is to essentially fork std::io and do work similarly to what I'm doing now, but coupling to librustuv instead. That seems like a large investment, and certainly something I have a hard time seeing happening in the next months. What are your thoughts on the long-term picture?

[aturon]

@alexcrichton Reminder, when this lands we need to investigate why gyp and libuv were still showing up on the mac bot, and remove the mentions in mk/tests.mk. For now I'm sending to bors with a reverted make tidy.