Hint/test stabilization: cannot keep TypeMirrors across javac context invocations.

[lahodaj]

Seeing the failure here: https://github.com/apache/netbeans/actions/runs/19711486484/attempts/1#summary-56473993246

it reminded me a similar problem elsewhere, so I took a look at the hint. In general, hint analysis and fix application may run in different javac contexts (different javac instances). It probably does not happen commonly, but it might, and it most likely happened in the test run above. And the Fix is keeping a TypeMirror from the analysis javac context, and tries to work with in the application context, which fails.

This PR is handling that using a TypeMirrorHandle.

As a follow-up work, we could try to enhance the test frameworks to always use a different javac instance for analysis and fix application, to avoid trouble like this.

---

^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)

[matthiasblaesing]

This looks suspiciously like a similar problem in PR #9005. @lahodaj would you mind having a look at that PR?

[mbien]

This PR is handling that using a TypeMirrorHandle.

now I know why this felt like a dejavu! I did something similar before and checked all JavaFix implementations for missing TreePathHandle creation in their constructors https://github.com/apache/netbeans/pull/8860#issuecomment-3336240429,

looked through it quickly again and checked TypeMirrors found one more copy/pasted issue: https://github.com/apache/netbeans/blob/3759cc54db547f8e271fe9adaa5d84fa53c53068/enterprise/web.jsf/src/org/netbeans/modules/web/jsf/hints/rules/JakartaFacesBeanIsGonnaBeDeprecated.java#L129-L130

https://github.com/apache/netbeans/blob/3759cc54db547f8e271fe9adaa5d84fa53c53068/enterprise/web.jsf/src/org/netbeans/modules/web/jsf/hints/rules/JavaxFacesBeanIsGonnaBeDeprecated.java#L129-L130

TypeElement needs to be wrapped. There doesn't seem to be a handle class for AnnotationMirror, but the usage there is a simple string comparison, so the string could be eagerly initialized in the constructor?