When mapping comments for modifiers of class members, make sure trailing comments for the preceding member are ignored.

[lahodaj]

While applying the TestNG->JUnit conversion, it turned out comments are sometimes duplicated. After some debugging, it happens if given code like:

class C {
    int f = 0; //trailing

    //preceding
    @Deprecated void t() {}
}

the comments are mapped for the @Deprecated (or mapped for the @Deprecated before other important mappings). The code will try to map the comments for the whole method, but as a consequence, it will assign the //trailing to the method as well. And when if the modifiers are changed, the comment may be duplicated.

The proposed change here is to do a "dry run" on the comment assignment for the preceding member, which should consume the trailing comment, and make sure the comments are assigned properly.

I tried some other cases where there are lists of elements, but so far this seems to only affect class members. If we later find more cases like this, it should be possible to generalize the handling, but tweaking specifically only class members seems sufficient for now.

---

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