[release/10.0] Cache debugger patches to speed up x64 stackwalk epilogue/prologue scanning

[github-actions]

Backport of #125459

Second partial fix for #122459

Caches the list of debugger breakpoint patches in the DAC so that x64 stack unwinding doesn't re-scan the patch hash table on every frame. During mini dump collection, each stack frame triggers DacReplacePatchesInHostMemory to restore original opcodes before reading memory — even though there are typically zero active patches during a dump. The patch hash table has 1,000 fixed buckets, so each call walked all of them regardless. The cache is populated once on first access and invalidated only on Flush().

Measured minidump collection against the same repro app with 10,000 iterations across 10 threads. The baseline was 55s, this change alone brings it to ~7s

/cc @hoyosjs

Customer Impact

• Customer reported
• Found internally

WER tries to collect dumps of crashing processes - this process can be extremely slow if the app has a lot of memory marshalling happening through the DAC. This particular hash is pretty bad for DAC access patterns.

Regression

This is a regression WRT to .NET Framework.

Testing

Manually collected dump and local perf testing

Risk

Low - DAC only path and this caches preexisting information.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.