refactor: introduce ModifierTarget for better dealing with modifiers

[SirYwell]

Previously, the getModifiers method had a isMethod boolean that was used to indicate that the modifiers are targetting a constructor or a method. Besides the vague naming, Java 17 introduces two new modifiers: sealed and non-sealed. Both of them require more context because their bits are used in different contexts too:

0x4000000
ExtraCompilerModifiers#AccIsDefaultConstructor
ExtraCompilerModifiers#AccBlankFinal
ExtraCompilerModifiers#AccNonSealed

0x10000000
ExtraCompilerModifiers#AccSealed
ExtraCompilerModifiers#AccPatternVariable
ExtraCompilerModifiers#AccOverriding

(this information was extracted with the ModifierConstantsCollector tool included in this PR).

One way to deal with that would be to add another boolean flag isType to check against, but I think it's a little bit clearer to use an enum. That makes it more readable and more expressive (and also more future proof).

I also added tests that help with implementing support for new modifiers.

[monperrus]

Thanks a lot, that's super interesting. The overall concept LGTM and explicit metadata in enums is good.

We need to javadoc and maybe better name ModifierTarget.

What's the meaning of ModifierTarget's values? The acceptable / possible modifiers for each element kind?

[SirYwell]

We need to javadoc and maybe better name ModifierTarget.

What's the meaning of ModifierTarget's values? The acceptable / possible modifiers for each element kind?

I agree, I'm not super happy with the name. Another idea for a name was ModifierContext, but it's all a little bit vague. Basically it is meant to describe the place where the modifiers belong to (like *public* class X, void myMethod(*final* Parameter param), *private static final* int i = 42.

As for now, only the AccTransient and AccVarArgs overlapped, so it was enough to distinguish between methods and everything else.

The set of allowed modifiers for such target/conext is currently only used for the tests but it would be possible to add validation of which modifiers are accepted to the different implementations (e.g. throw an exception or just ignore it if someone tries to add the public modifier to a local variable).

[SirYwell]

I rebased and resolved the conflicts. As I was surprised by #4205 myself, it might be even easier to support sealed classes correctly. I think this PR is the only blocker then for now.

[monperrus]

LGTM. I cannot find a better name.

Let's javadoc ModifierTarget and we're done.

[SirYwell]

I added some javadoc.

The enum is currently package private and only used for the JDTTreeBuilder to avoid more boolean flags on the getModifiers method. We can make it public in future, probably making it a property of CtModifiable and automatically checking if a modifier is valid in the CtModifierHandler. But I would consider that a separate feature (and we can still change the name then).

[monperrus]

thanks, we fix the conflict and merge.

[monperrus]

Thanks a lot @SirYwell