Reland rustwide and tokio upgrade

[jyn514]

The cause of the leak was that Regex::new leaked 2.5 MB of memory on
every build (in parse_rustc_version). Searching around I found
rust-lang/regex#742, which said this was a
regression in thread_local. Updating thread_local to 1.1.3 fixed the
issue.

For future reference: I debugged the leak as follows.

1. Build the crate: cargo build
2. Run the daemon under massif without registry watching: valgrind --tool=massif target/debug/cratesfyi daemon --registry-watcher disabled
3. Add a whole bunch of crates to the queue: for i in $(seq 1 100); do cargo run -q queue add serde 1.0.$i; done
4. Stop the daemon with SIGINT when you get tired of waiting (I ran about 30 builds).
5. Run massif-visualizer on the generated file.

Successor to #1264. Fixes #1102. Unblocks #1303.

This is a WIP because I tested the leaks with an ancient version of the lockfile, not the one in this PR; I need to test again before this merges.

[jyn514]

Ok cool, I ran about 80 builds with no leaks.

[Nemo157]

Code looks good, I'm setting up an overnight test running builds to see if I get any leaks.

[Nemo157]

I ran 200 builds on the server running in the docker-compose setup, checking the rss usage after each build:

for i in $(seq 1 200); do
  cargo run -- queue add bs58 0.4.0 2>/dev/null
  sleep 180
  ps -C cratesfyi -o rss --no-headers
done

There is what looks like a slight leak, but it might just be heap fragmentation or something. It's the same as what I previously saw when testing e8a6303, I didn't record the full data the same as this, but at that version after 10 builds it was at 69MB and after 100 builds was at 173M, which are right on the line.

Comparatively when testing 48444ef at 10 builds it had reached 109MB and 100 builds it had reached 530MB, so significantly more leakage.