Auto merge of rust-lang#138871 - smoelius:librustdoc-fx-index-map, r=<try>

Change one `FxHashMap` to `FxIndexMap` in librustdoc

This PR changes one `FxHashMap` to `FxIndexMap` in librustdoc's cache and adds a comment explaining why (i.e., to promote reproducibility across operating systems).

I have been [trying to understand](rust-lang/rustdoc-types#44) why the following command produces different results on Linux and MacOS when run on a project whose lib.rs contains only `#![no_std]`:
```sh
cargo rustdoc --target x86_64-unknown-linux-gnu -Zbuild-std -- -Z unstable-options --output-format=json
```
I obtained a partial answer in that elements were being read out of this `FxHashMap` in different orders, even when the elements were inserted in the same order: https://github.com/rust-lang/rust/blob/aa8f0fd7163a2f23aa958faed30c9c2b77b934a5/src/librustdoc/formats/cache.rs#L50

I [opened an issue](rust-lang/hashbrown#612) on the Hashbrown repo to see whether this was a bug. The response I got was that if one wants the elements to be read out in the same order, one should use something like `FxIndexMap`.

cc: `@aDotInTheVoid`

Author: bors

src/librustdoc/formats/cache.rs

@@ -28,6 +28,12 @@ use crate::visit_lib::RustdocEffectiveVisibilities;
 /// to be a fairly large and expensive structure to clone. Instead this adheres
 /// to `Send` so it may be stored in an `Arc` instance and shared among the various
 /// rendering threads.
+///
+/// To promote reproducibility across operating systems, this structure
+/// intentionally does not use [`rustc_data_structures::fx::FxHashMap`].
+/// Elements can be stored in deferent orders in an `FxHashMap`, even if the
+/// elements are inserted in the same order. Wherever an `FxHashMap` would be
+/// needed, an [`rustc_data_structures::fx::FxIndexMap`] is used instead.
 #[derive(Default)]
 pub(crate) struct Cache {
     /// Maps a type ID to all known implementations for that type. This is only
@@ -47,7 +53,7 @@ pub(crate) struct Cache {
 
     /// Similar to `paths`, but only holds external paths. This is only used for
     /// generating explicit hyperlinks to other crates.
-    pub(crate) external_paths: FxHashMap<DefId, (Vec<Symbol>, ItemType)>,
+    pub(crate) external_paths: FxIndexMap<DefId, (Vec<Symbol>, ItemType)>,
 
     /// Maps local `DefId`s of exported types to fully qualified paths.
     /// Unlike 'paths', this mapping ignores any renames that occur