Properly track DepNodes in trait evaluation provisional cache

[Aaron1011]

Fixes #92987

During evaluation of an auto trait predicate, we may encounter a cycle.
This causes us to store the evaluation result in a special 'provisional
cache;. If we later end up determining that the type can legitimately
implement the auto trait despite the cycle, we remove the entry from
the provisional cache, and insert it into the evaluation cache.

Additionally, trait evaluation creates a special anonymous DepNode.
All queries invoked during the predicate evaluation are added as
outoging dependency edges from the DepNode. This DepNode is then
store in the evaluation cache - if a different query ends up reading
from the cache entry, it will also perform a read of the stored
DepNode. As a result, the cached evaluation will still end up
(transitively) incurring all of the same dependencies that it would
if it actually performed the uncached evaluation (e.g. a call to
type_of to determine constituent types).

Previously, we did not correctly handle the interaction between the
provisional cache and the created DepNode. Storing an evaluation
result in the provisional cache would cause us to lose the DepNode
created during the evaluation. If we later moved the entry from the
provisional cache to the evaluation cache, we would use the DepNode
associated with the evaluation that caused us to 'complete' the cycle,
not the evaluatoon where we first discovered the cycle. As a result,
future reads from the evaluation cache would miss some incremental
compilation dependencies that would have otherwise been added if the
evaluation was not cached.

Under the right circumstances, this could lead to us trying to force
a query with a no-longer-existing DefPathHash, since we were missing
the (red) dependency edge that would have caused us to bail out before
attempting forcing.

This commit makes the provisional cache store the DepNode create
during the provisional evaluation. When we move an entry from the
provisional cache to the evaluation cache, we create a new DepNode
that has dependencies going to both of the evaluation DepNodes we
have available. This ensures that cached reads will incur all of
the necessary dependency edges.

[rust-highfive]

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

[michaelwoerister]

Thanks, @Aaron1011! The fix looks valid to me. Great comments!

@bors r+

[bors]

📌 Commit 02f1a56 has been approved by michaelwoerister

[pnkfelix]

should this have had a perf run? (I'm trying to track down what caused some performance deltas in rollup PR #93288.)