Implement a new approach to consistent crate failures

[aidanhs]

Some crates consistently fail to build. The docker image currently installs 'a bunch of stuff' in the hope this will help more crates build, but there are things like tex manpages in there.

We should have a more principled approach to this:

• every now and again, do a recheck run of all crates with a disabled stage to see if they've been fixed
• during these recheck runs, do an analysis on failures and partition them into a) broken code, b) broken env, c) other
• for broken env, identify whether we want to increase the size of the docker image

Once this is in place, we can start reducing the size of the existing docker image. By selectively removing packages and seeing what breaks.

Other more exciting approaches are possible as well, like reselecting a small number of random crates to be re-tested on every run - small % impact per run, but means we get to handle it incrementally.

See also:

• https://github.com/rust-lang-nursery/crater/issues/155
• https://github.com/rust-lang-nursery/crater/pull/195#issuecomment-373246337

[pietroalbini]

every now and again, do a recheck run of all crates with a disabled stage to see if they've been fixed

Maybe we can do a recheck on the first beta run of each cycle? It doesn't happen too frequently, and it can potentially catch more regressions.

[Mark-Simulacrum]

I'd prefer to avoid doing anything special with beta runs as those are fairly critical to Rust's stability guarantees, but otherwise this seems fine.

[aidanhs]

IIRC beta is restricted to just using stable features, but we want to be as permissive as possible when enabling crates - arbitrary nightlies seem like the best bet. Maybe the nightly that gets promoted to beta.