stop using custom rustc/cargo

[QuietMisdreavus]

This PR was a long time coming, and took some effort to coordinate and put together. Huge thanks to @jonhoo for setting up a dev environment that i could use to test this out!

This PR does a handful of things, namely:

• Switch the cargo dependency from onur's fork to upstream.
  • This caused a lot of fallout in the code, since onur's fork was based on an old version of cargo.
  • This also forced several unrelated dependencies to update, since they depended on different versions of openssl-sys or libgit2, which caused Cargo to reject the lockfile.
  • However, this also allows crates to set editions and generally treat cargo as if it were nightly. (We'll need to manually update the lockfile to update cargo, though, including updating our use of it should the API change. Consider it a future task to switch to shelling out to cargo itself.)
• Switch the internal error type from an error-chain enum to failure's Error type.
  • This was semi-required by the Cargo update, since it had switched to failure itself and its error type no longer worked as a foreign link in error-chain.
• Set --extern-html-root-url in the rustdoc flags when building documentation for a crate.
  • This allows us to switch from onur's custom rustdoc fork to nightly rustdoc, allowing lots and lots of crates to start building and making compiler updates much easier in the future.

Sorry for totally obliterating the lockfile - it was easiest for me to make it totally regenerate it as part of the cargo upgrade. Without regenerating the lockfile, i was getting odd errors compiling seemingly unrelated dependencies.

This probably fixes so many posted issues here, but i haven't looked through them all. >_>

[jonhoo]

Awesome work! For those who are curious, this new version runs on http://docsrs.csail.mit.edu/. Old crates haven't been built there yet, but new ones should be!

[QuietMisdreavus]

@onur Should i update the Vagrantfile in this PR to reflect the rustc in use on the development server? Since this PR fully supports a recent nightly rustc/rustdoc, we can update the development configuration to reflect the supported compiler version. (Though i understand that updating docs.rs itself will have to happen on the server, not just in the Vagrantfile.)