Fix tree threading in fgOptimizeBranch (#51422)

In case `fgOptimizeBranch` gets far enough to calculate the cost of
statements it is considering duplicating, then it calls `gtPrepareCost` =>
`gtSetEvalOrder` to compute a statement's costs. Unfortunately, that
can reverse operands (and in this case, did). `fgOptimizeBranch` is
called only by `fgReorderBlocks` which is called by `fgInsertGCPolls`,
late enough that the tree is already threaded with gtNext/gtPrev links.
(The test case inserted multiple GC polls for SuppressGCTransitionAttribute
code.) When the operands of the tree were swapped, nobody fixed up these links.
The only other caller of `fgReorderBlocks` is `optOptimizeLayout`, which
comes before the trees are threaded.

The solution is to simply call `fgSetStmtSeq` if needed.

No SPMI x86, x64 asm diffs.

Fixes #51293, a failure in JIT/Performance/CodeQuality/Burgers/Burgers/Burgers.sh
on Linux arm32 under JitStress=1. There is IBC data, and setting
`COMPlus_JitDisablePgo=1` also fixes the failure.

Author: BruceForstall

src/coreclr/jit/fgopt.cpp

@@ -3376,11 +3376,17 @@ bool Compiler::fgOptimizeBranch(BasicBlock* bJump)
     unsigned estDupCostSz = 0;
     for (Statement* stmt : bDest->Statements())
     {
-        GenTree* expr = stmt->GetRootNode();
+        // We want to compute the costs of the statement. Unfortunately, gtPrepareCost() / gtSetStmtInfo()
+        // call gtSetEvalOrder(), which can reorder nodes. If it does so, we need to re-thread the gtNext/gtPrev
+        // links. We don't know if it does or doesn't reorder nodes, so we end up always re-threading the links.
 
-        /* We call gtPrepareCost to measure the cost of duplicating this tree */
-        gtPrepareCost(expr);
+        gtSetStmtInfo(stmt);
+        if (fgStmtListThreaded)
+        {
+            fgSetStmtSeq(stmt);
+        }
 
+        GenTree* expr = stmt->GetRootNode();
         estDupCostSz += expr->GetCostSz();
     }