JIT: Move return merging from fgAddInternal to a late phase

[EgorBo]

Currently, we perform tail merging in fgAddInternal phase which is performed right after inlining. There, we minimize the number of tails (BBJ_RETURN) to 4 (I guess it's driven by legacy jit32 gc encoder having a hard limit on epilogues, but we use this threshold for other targets as well). It seems that it might break some control-flow optimizations, should we move this merging to a later phase? ideally when we know exactly the cost of an epilogue.

cc @AndyAyersMS @amanasifkhalid @dotnet/jit-contrib

[dotnet-policy-service]

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

[AndyAyersMS]

Also see #8406, #8883

[jakobbotsch]

One thing to consider is also how to handle multi-reg returns properly in these scenarios. Today we introduce the shared return temp as part of the return merging, which happens before promotion, so the return temp naturally gets promoted and multi-reg returns work fine in these scenarios.
If we do this later we will likely need to do some manual (physical) promotion of the shared return temporary that we end up introducing, in combination with something like #86665 to actually allow returning its fields in registers.