Auto merge of #144722 - ywxt:parallel-reproducibile, r=SparrowLii

Fix parallel rustc not being reproducible due to unstable sorts of items

Currently, A tuple `(DefId, SymbolName)` is used to determine the order of items in the final binary. However `DefId` is expected as non-deterministic, which leads to some not reproducible issues under parallel compilation. (See rust-lang/rust#140425 (comment))

Theoretically, we don't need the sorting because the order of these items is already deterministic.

However, codegen tests reply on the same order of items  between in binary and source.

So here we added a new option `codegen-source-order` to indicate whether sorting based on the order in source. For codegen tests, items are sorted according to the order in the source code, whereas in the normal path, no sorting is performed.

Specially, for codegen tests, in preparation for parallel compilation potentially being enabled by default in the future,  we use `Span` replacing `DefId` to make the order deterministic.

This PR is purposed to fix rust-lang/rust#140425, but seemly works on rust-lang/rust#140413 too.

This behavior hasn't added into any test until we have a test suit for the parallel frontend. (See rust-lang/rust#143953)

Related discussion: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fparallel-rustc/topic/Async.20closures.20not.20reproducible.28.23140425.29) rust-lang/rust#144576

Update rust-lang/rust#113349

r? `@oli-obk`
cc `@lqd` `@cramertj` `@matthiaskrgr` `@Zoxc` `@SparrowLii` `@bjorn3` `@cjgillot` `@joshtriplett`

Author: bors