Fix non-deterministic DXIL/PDB output for resource arrays (#8171)

[damyanp]

DxilMutateResourceToHandle iterates a DenseSet<Value *> to process ConstantExpr GEPs on resource array globals. DenseSet iteration order depends on pointer hash values, which vary across runs due to ASLR. For each GEP, mutateCandidates() destroys the old ConstantExpr and creates a new one, prepending it to the global's use list. The non-deterministic processing order produces a non-deterministic use list, which TranslateDxilResourceUses later iterates to create named handles - resulting in different name suffixes across compilations.

The fix is to change MutateValSet from DenseSet<Value *> to SetVector<Value *>, which preserves insertion order while maintaining O(1) lookup. Since collectCandidates() traverses the IR in a deterministic order, the insertion order is stable, producing a deterministic use list and consistent handle names.

Fixes #8171

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[bogner]

If we were doing a larger refactor here I would strongly suggest that we modify the algorithm into a stricter insert-than-query approach, especially given how painfully close it is to one today.

However, for a small code change that trades some extra memory overhead for determinism this looks perfectly reasonable.