Improving code completion in presence of local classes.

[lahodaj]

I was looking at bug #9199 which regards to local classes (i.e. classes inside method bodies). The ultimate cause is that the code completion uses TreeUtilities.parseType(String, TypeElement). Basing type attribution on a class will obviously not allow to resolve local classes - inside one class, there may be any number of local classes with the same name, among many other problems.

The main part of this PR is an addition of Scope-based version of TU.parseType. I tried to use this new variant across the code completion code (except one place, where I can't convince myself the replacement makes sense).

As a side-change, when one invokes the CC after e.g.:

new String

the CC will contain the String constructors, but not the String class. But invoking it after e.g.:

new java.lang.String

both the constructors and the class will be present, as the exclude is not done in this context. This PR adds the exclude at two places (mostly because I couldn't convince myself the tests should have different outcomes).

I left two TODO/NOTE in the patch for now, where we can discuss if the behavior is correct. I'll remove the TODOs when appropriate.

Tests added for hopefully all the places in the CC that were modified.

Additional side-changes are:

• added a workaround into NBAttr, so that getting scope for CaseTree/JCCase "works"
• the apichanges DTD only had years until 2025. Adding a new version of the DTD, and adding years until 2100

closes #9199

---

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