Refactor call counting for tiering and some other things (dotnet/coreclr#26393)

Refactor call counting for tiering and some other things (dotnet/coreclr#26393)

Refactor call counting for tiering and some other things

- Moved call counting to after jitting is done, when the tier of the code becomes clear. Passed info back about whether the method should be recorded for call counting through the `PrepareCodeConfig` to avoid some more expensive rechecks.
- Moved checks for aggressive optimization and QuickJit to the point when JIT flags are determined
- Specialized `PublishVersionalbeCodeIfNecessary` for methods versionable with and without a jump stamp
- Added fast paths for cases operating on the default native code version to avoid code versioning overhead during startup
- Methods are not counted on first call, only recorded for counting later. First call to a method is determined by whether the thread generated or loaded code for the method. Threads that wait for jitting to complete don't count calls either. Once the method already has native code and goes through the prestub, its calls are counted.
- Overall, time spent in DoPrestub decreased noticeably when tiering is enabled, almost the same as with tiering disabled typically. Small improvement to startup time, seems to decrease by a few milliseconds.
- Fixed a bug where, when call counting for a method stops due to the tiering delay being activated, it was extending the delay as though it were the first call to the method
  - This was noticably increasing time taken to reach steady-state perf by keeping the delay active for longer than necessary. After the fix, steady-state perf is reached sooner without any noticeable overhead in-between.
  - A fix creates a potential race between thread A recording a method to be counted later, thread B resetting the method's entry point for counting calls, then thread A setting the tier 0 code as the entry point, and the method would not be tiered up. For now I decided to stop call counting only when a flag that would extend the delay timer is set, with other planned work this code and issue would go away.
- Miscellaneous small changes

Commit migrated from https://github.com/dotnet/coreclr/commit/6e72575313deeb3a5891324661fcc1287ded3325