Auto merge of #13989 - epage:target-sort, r=weihanglo

fix(toml): Ensure targets are in a deterministic order

### What does this PR try to resolve?

With #13713, we enumerate all targets in `Cargo.toml` on `cargo publish` and `cargo vendor`.
However, the order of the targets is non-determistic. This can be annoying for comparing the published `Cargo.toml` across releases but even worse is the churn it causes for `cargo vendor`.

So we sort all the targets during publish.
This keeps costs minimal with the following risks
- If the non-determinism shows up in a way that affects developers during development
- If there is a reason the user wants to control target order for explicit targets

Fixes #13988

### How should we test and review this PR?

As for writing of tests, I'm unsure why none of our existing tests failed which makes it unclear to me what would be needed to write a test for this.

### Additional information

src/cargo/util/toml/mod.rs

@@ -2777,6 +2777,11 @@ fn prepare_targets_for_publish(
         };
         prepared.push(target);
     }
+    // Ensure target order is deterministic, particularly for `cargo vendor` where re-vendoring
+    // shuld not cause changes.
+    //
+    // `unstable` should be deterministic because we enforce that `t.name` is unique
+    prepared.sort_unstable_by_key(|t| t.name.clone());
 
     if prepared.is_empty() {
         Ok(None)