Simplify the dead thread-group fallback left by SystemGetSecurityManagerToNull

[jkschneider]

After System.getSecurityManager() becomes null, the common idiom

SecurityManager s = null;
ThreadGroup group = s != null ? s.getThreadGroup() : Thread.currentThread().getThreadGroup();

keeps a dead local and a dead branch; SimplifyConstantIfBranchExecution handles if, not this ternary. New SimplifySecurityManagerThreadGroup, added to the composite right after the replacement: when a null SecurityManager local is used only in the immediately following s != null ? s.getThreadGroup() : <fallback> assignment, drop the local and assign the fallback. Anything with comments, more references or another shape is left alone (the second commit adds the comment guards).

Found by a team of coding agents reviewing a Moderne run of org.openrewrite.java.migrate.UpgradeToJava25 over eight open-source repositories (run 20261003103223-WtyA8). The issue is security-manager-null-local in the run's io.moderne.RecipeIssues data table, and the fix was discussed and reviewed on the run's message board. A row from the table, as a generalized example:

Replacing getSecurityManager with null leaves a dead local and a dead conditional branch. (rrd4j/rrd4j, src/main/java/org/rrd4j/core/RrdSyncThreadPool.java)

Before:

SecurityManager s = System.getSecurityManager();
ThreadGroup group = s != null ? s.getThreadGroup() : Thread.currentThread().getThreadGroup();

What the recipe produced:

SecurityManager s = null;
ThreadGroup group = s != null ? s.getThreadGroup() : Thread.currentThread().getThreadGroup();

Expected:

ThreadGroup group = Thread.currentThread().getThreadGroup();

Stacked on #1254 (6 of 9); merge that one first.