`push` should likely push to latest HEAD, not the commit recorded in rust-version

See this discussion: a long time ago when Miri was the only tool using josh, I made it so that the push logic roughly does the following:

• Prepare a branch in RalfJung/rust that is set to exactly the commit currently configured in the rust-version file
• Tell josh to push to that branch

If I remember correctly, I did this because I got some strange problems once when pushing to the latest rust-lang/rust HEAD and this made things more deterministic. However, this makes one non-trivial demand on Josh. Consider the case where one does two push syncs without an intermediate pull: the second push will now re-do the work of the first, since both of them are asked to reconstruct the subrepo history on the main repo from the same starting point. If for some reason Josh is not fully deterministic in how it reconstructs such history during a push, then the 2nd push will duplicate commits from the first. That is exactly what happened with RA in the Zulip thread linked above.

@christian-schilling recommends that we should push on top of the latest rust-lang/rust HEAD rather than the commit recorded in rust-version. That would avoid relying on determinism during push syncs. I don't know which strange problems I got when I decided to introduce this logic that always pushes on top of rust-version, but we can hope that if it happens again, it would be caught by the round-trip check.

Start by tracing the push logic that prepares a branch from the commit in rust-version, then inspect how Josh is invoked for push syncs. Compare that behavior with pushing on top of the latest rust-lang/rust HEAD and review the linked Zulip discussion for context. Done means repeated push syncs do not duplicate commits and the round-trip check still passes.