Converting our travis/appveyor CI to do full release builds. By doing release builds on every platform on every commit we should stop breaking nightlies so much.

• switch homu to travis/appveyor, leaving buildbot in place (#38536 (comment))
• modify rustbuild to build stage1 by default, with option for stage2 (#38631)
• add stage2 bootstrap bot to verify the full bootstrap works (#38631)
• add sccache to bots (#38359)
• add remaining cross-host rustc/platform builders
• add distcheck bot (#38708)
• add --enable-platform
  • on "make dist" (temporarily) pulls cargo from s3 and builds combined installers
  • teach rustbuild pkg / msi
• have rustbuild produce .sha256 files on all dist output (#38748)
• modify all builds to 'make dist' and upload (#38748)
• confirm all matrix entries are correct
• add cargo submodule
• for --enable-platform compile/test/dist cargo

cc @alexcrichton

re https://internals.rust-lang.org/t/rust-ci-release-infrastructure-changes/4489

modify rustbuild to build stage1 by default, with option for stage2

What's the expected approach to dealing with situations where cfg(stage0) or cfg(not(stage0)) is currently used? Currently, since stage0 is bootstrap (old compiler) and stage1 is a new compiler, there is a transition path, but with this I'm not sure what the expected arguments to x.py are.

@alexcrichton will need to address those details @Mark-Simulacrum.

@Mark-Simulacrum you may be interested in #38631, but the gist is that nothing changes, it's all the same. It may not be clear what terminology means what, but #38631 as a concrete implementation should hopefully clarify what's intended.

So instead of stage0 we should now cfg(stage1)?

Perhaps a better way to ask my question is: when changes are made to the compiler that make a given lang item no longer necessary, what cfg should it be annotated with?

Oh no everything should proceed as usual. When the compiler changes a lang item you use #[cfg(stage0)] and #[cfg(not(stage0))], as we do today.

Is there something specific, though, that you're worried about breaking?

In #38574, I removed the trans_exchange_free lang item, and as such a compile with --increnental (which I understand is equivalent to the changes suggested above) failed since the beta compiler expected it to be defined. Perhaps I missed something, though.