Consolidate morphing of local nodes

[SingleAccretion]

This change creates a new entrypoint for morphing of all local nodes - fgMorphLocal, and utilizes it to remove the restriction on morphing of "x86 stack args under varargs" in LocalAddressVisitor, in preparation of doing the same with implicit byrefs.

Diffs: we have some TP regressions; I have traced them down to MSVC not inlining things, e. g. if I put FORCEINLINE on fgMorphLeaf, I get a negative PIN diff overall. I hope our PGO builds will make up for this. Additionally, the upcoming implicit byref change has some very nice TP wins attached to it.

We also have (expected) GC info diffs:

-      lea      edx, bword ptr [ebp+08H]
-      ; byrRegs +[edx]
+      lea      edx, [ebp+08H]
       call     [hackishModuleName:hackishMethodName()]
-      ; byrRegs -[edx]

The reason is that we now transform the address of the varargs cookie itself to LCL_VAR_ADDR:

-               [000004] ----------- arg1                    \--*  ADDR      byref
-               [000003] -------N---                            \--*  LCL_VAR   int   (AX) V01 VarArgHandle
+               [000004] ----------- arg1                    \--*  LCL_VAR_ADDR byref  V01 VarArgHandle

And so the rationalizer doesn't retype it back to TYP_BYREF:

 *************** Starting PHASE Rationalize IR
-Rewriting GT_ADDR(GT_LCL_VAR) to GT_LCL_VAR_ADDR:
-N002 (  3,  2) [000003] -------N---                    t3 =    LCL_VAR_ADDR byref  V01 VarArgHandle

[ghost]

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

Issue Details

---

This change creates a new entrypoint for morphing of all local nodes - fgMorphLocal, and utilizes it to remove the restriction on morphing of "x86 stack args under varargs" in LocalAddressVisitor, in preparation of doing the same with implicit byrefs.

We're not expecting diffs.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[SingleAccretion]

Build windows x64 debug NativeAOT failed with what looks like #69192. There is also a timeout; not sure what it is about, but seems quite unlikely to be related to this almost zero-diff change.

@dotnet/jit-contrib