Properly re-use def path hash in incremental mode

Fixes #79661

In incremental compilation mode, we update a `DefPathHash -> DefId`
mapping every time we create a `DepNode` for a foreign `DefId`.
This mapping is written out to the on-disk incremental cache, and is
read by the next compilation session to allow us to lazily decode
`DefId`s.

When we decode a `DepNode` from the current incremental cache, we need
to ensure that any previously-recorded `DefPathHash -> DefId` mapping
gets recorded in the new mapping that we write out. However, PR #74967
didn't do this in all cases, leading to us being unable to decode a
`DefPathHash` in certain circumstances.

This PR refactors some of the code around `DepNode` deserialization to
prevent this kind of mistake from happening again.

compiler/rustc_query_system/src/dep_graph/dep_node.rs

@@ -53,6 +53,19 @@ use std::hash::Hash;
 #[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash, Encodable, Decodable)]
 pub struct DepNode<K> {
     pub kind: K,
+    // Important - whenever a `DepNode` is constructed, we need to make
+    // sure to register a `DefPathHash -> DefId` mapping if needed.
+    // This is currently done in two places:
+    //
+    // * When a `DepNode::construct` is called, `arg.to_fingerprint()`
+    //   is responsible for calling `OnDiskCache::store_foreign_def_id_hash`
+    //   if needed
+    // * When a `DepNode` is loaded from the `PreviousDepGraph`,
+    //   then `PreviousDepGraph::index_to_node` is responsible for calling
+    //   `tcx.register_reused_dep_path_hash`
+    //
+    // FIXME: Enforce this by preventing manual construction of `DefNode`
+    // (e.g. add a `_priv: ()` field)
     pub hash: PackedFingerprint,
 }