Figure out rust-lang/rust testing strategy

[ehuss]

I think it will be important for build-std to be tested in the rust-lang/rust CI. However, since the cargo side is so tightly coupled with the structure of the std source tree, that will make things difficult (particularly if a change needs to happen in both repos).

Some rough thoughts and ideas:

• We could use something like rust-toolstate to track failures in build-std. I'm not terribly enthusiastic about that, since rust-toolstate in general was an unpleasant system. Also, a breaking change in rust-lang/rust would break cargo's CI. Cargo's CI could pin a nightly, but then cargo would need to very frequently update that.
• We could use something like git subtrees. I don't particularly feel comfortable trying to track changes that happen on the rust-lang/rust side, and I don't have confidence that everyone with review rights will avoid making changes to src/tools/cargo without conferring with the team. It also puts a larger burden on our update process, and release processes (though it is unclear how much).
• Reduce how tightly coupled cargo is with how std is built. This would be good in general, but I am skeptical that we can completely remove all coupling.
• We'll need to decide which targets get tested and how.
  • Somewhat related to this is how much CI time can be afforded. I think building std takes about a minute, but building cargo's testsuite to run the tests could take longer since that would need building all of cargo (as a test). We might need some separate test suite that is independent of cargo.

Subtrees seem to be the most feasible solution, but I'm not particularly excited about them.

[Noratrieb]

Many projects like Miri are now using JOSH instead of git-subtree, which reduces some of the pains of subtrees.