Don't automatically update submodules when running `x.py`

[oli-obk]

#53916 (comment) noted that the submodules setting of config.toml is not very discoverable.

I have set it to false in all my trees and update my submodules manually, because I've had work destroyed multiple times when I changed submodule contents and x.py killed them without asking by force updating the submodule to the commit checked into the rustc repo.

There are a few (not mutually exclusive) ways to improve this:

1. don't update submodules if they are dirty (modified files, new files)
2. don't update submodules if the current commit is newer than the one x.py wants to update to (so only go forward automatically, not backwards)
3. set submodules = false by default (might inconvenience developers that never touch submodules, I am biased here due to touching clippy and miri on a very regular basis)

cc @nnethercote @rkruppe

[petrochenkov]

Minus to 3.
Before #49057, when submodule update was slow (especially on Windows), I had to disable it by default and enable when necessary, and it was very very annoying, I wouldn't want to do that again.

[dotdash]

2 should say something like "only update if it's a fast forward" or something along those lines to cover non-linear commit histories.

Personally, I always add changed submodules to the index, temporarily committing changes in the submodule if needed . That stops git submodule update from throwing away my changes because my commit is now the one to update to. And as a bonus, git pull will complain if the submodule was changed upstream, so I don't get builds that surprisingly fail because of outdated submodules, which I used to get rather often when I used method number 3.

[oli-obk]

We're moving away from submodules, so this is becoming irrelevant