Symbol order in executable unstable with v0 mangling when -Cmetadata changes

In items_in_deterministic_order we sort the mono items by symbol name. With the legacy symbol mangling only the hash at the end changes whenever -Cmetadata changes, so unless you have two versions of the same crate, the symbol order will be fairly consistent between rustc and crate versions (though different instantiations of a generic function will still have a different order depending on -Cmetadata). However for the v0 mangling, there is already a hash at the start, producing wildly different symbol orders between rustc and crate versions.

This make performance less predictable between rustc versions and makes it harder to diff two versions of an executable (for example to check if the only reason an executable is non-reproducible is -Cmetadata differences resulting in different symbol names and crate metadata or if the actual contents of the executable differ).

One option to fix this would be to first sort on the symbol name excluding crate disambiguator and only after that sort on the crate disambiguator where there are multiple symbols that only differ in crate disambiguator.

Start at items_in_deterministic_order, where mono items are sorted by symbol name, and inspect how v0 and legacy mangled names affect that ordering. Compare ordering across -Cmetadata changes and rustc or crate versions. Done means symbols are sorted consistently while still using the crate disambiguator to break ties between otherwise identical names.