JIT: Remove fgMoveHotJumps

[amanasifkhalid]

Part of #107749. Based on the plans outlined in #111989 (comment), we should rely on 3-opt to improve upon the baseline RPO layout; fgMoveHotJumps is a meek approximation of the former. Removing fgMoveHotJumps churns the initial layout into 3-opt, which seems to redirect it to a different local optimum with some frequency. The cases where the new local optimum is worse aren't a justification for fgMoveHotJumps's existence, but motivation for improving 3-opt's ability to find globally-optimal layouts.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[amanasifkhalid]

cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Diffs are particularly large on x86/x64, where we have variable-length jumps. A common theme I'm seeing in the diffs is where we have some straight-line code that can be entered via more than one predecessor, but the layout improvement for preferring one predecessor over the other is insignificant, so 3-opt now moves a large chunk of code up/down the method, potentially changing the sizes of the jumps inside the range. Such examples usually have large size diffs, but little/no PerfScore diff.

TP diffs are a wash; in spending less time on the initial layout, 3-opt has to do more work in some cases. I think I can get the cost of a 3-opt run down a bit in the next few PRs, so hopefully I'll make up for this... Thanks!