Tiered jitting: Review/fix ICorDebug interactions

[noahfalk]

PR dotnet/coreclr#12193 - took an initial stab at this but it is incomplete. We need to:

• Confirm that the debugger areas that PR changed are working properly
• Disable tiered jitting when requested to do debuggable code-gen. This ensures that native-IL mapping stays at high quality, inlining doesn't occur, and there is no intersection between EnC and tiered jitting.
• Fix race conditions that could otherwise occur when new code versions are created while breakpoints/tracing is active in the previous code version. A canonical scenario is likely to be:

1. Developer is stopped in the debugger in the Foo function which is about to call Bar
2. Developer issues a step-in which binds a breakpoint at the entrypoint of Bar jitted code version 1.
3. Debugger resumes execution of all threads, planning to stop again once the current thread reaches the Bar jitted version 1 breakpoint.
4. On a seperate thread the background optimized compilation of Bar completes, jitted code version 2. This new code version is published.
5. The original call from from Foo to Bar executes the updated stubs and winds up invoking the code for Bar jitted code version 2. This version didn't have a breakpoint in it thus the debugger doesn't stop.

A correct implementation would need to replicate some of the breakpoints from version 1 to version 2 prior to the new version being published. Breakpoints that are tracked in the runtime by IL offset are probably correctly applied already, but those that are tracked by native offset aren't. Breakpoints used for stepping as above are one example of that class.

Note: Despite excluding debuggable code-gen from getting tiered, the debugger/ICorDebug API is not restricted to only operate on debuggable code. Stepping may skip around a bit more erratically in retail code, but failing to stop doesn't seem reasonable.

[Pzixel]

About race conditions: maybe it's easier to not replace code while someone is inside? Just create a gate, and if method is recompiled, we redirect all new calls to stub. When all calls left method which is about to recompile we replace it and new calls pass through this stub and resume their work.

[noahfalk]

In my example above it is already the case that no thread is executing inside Bar when it is replaced : ) However the main thorny issue is that trying to track thread entry/exit adds performance overhead to every method invocation. We want to try pretty hard to keep that overhead to the bare minimum.

[noahfalk]

Breaking this down into multiple issues:
dotnet/coreclr#14418

[noahfalk]

dotnet/coreclr#14421

[noahfalk]

dotnet/coreclr#14423

[noahfalk]

dotnet/coreclr#14426

[noahfalk]

dotnet/coreclr#14427

[noahfalk]

dotnet/coreclr#14428

[noahfalk]

All of the known sub-issues have been resolved, work complete!