[GITHUB-9198] Do not remove for each variables, even if unused.

[lahodaj]

For code like:

for (String s : java.util.List.of("")) {}

the s is unused, and there's a fix proposed to remove the variable. That obviously cannot work.

There's already a check in Unused that disables that fix for binding patterns/variables. It could be enhanced for the for each, but it does not feel right - the JavaFixUtilities.safelyRemoveFromParent should do that.

So, this PR tweak JavaFixUtilities.safelyRemoveFromParent so that it won't try to remove the binding variables, and for-each variables.

It also adds a new fix to change the name of the variable to _, for source level >= 22.

closes #9198

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[mbien]

The fix itself works as far as I can tell, the new RenameToUnderscore works also.

In future we could also try update the unused detector to show unused exception params, and other params like in lambdas. I think some of those are intentionally ignored atm before they even hit the hint.

        try {
            int p = Integer.parseInt("1");
        } catch (NumberFormatException ignore) {}

        Map.of().computeIfAbsent("key", k -> "value");

so that ignore and k are both suggested as _ candidates (right now its only p which is valid but probably not super useful)

[mbien]

now unused