Generated by 🚫 Danger

@adangel We could use several Modifiers productions in the future. Eg FieldModifiers wouldn't accept the abstract modifier, etc. This would remove the need for the lookaheads I introduced here, but would hide modifier errors behind a syntax error, which is super ugly, Javacc being what it is.

Alternatively we could just have the Modifiers production check for the modifier incompatibilities, that could break a PMD run. In particular I'm thinking about

• specifying more than one access modifier, which could mess with many rules and with accessibility resolution for type resolution
• specifying both "abstract" and "final" or "abstract" and "private"
• or specifying an access modifier for a local class

I wouldn't care too much about completely absurd modifier combinations like a default class, because no rule would consider this possibility, so it couldn't break the assumptions we make for analysis

However I think the API of nodes should not expose methods for such absurd modifiers. So, ClassOrInterfaceDeclaration shouldn't have a isDefault method. We should split AccessNode I think. Probably the only thing we can share between all AccessNodes is the access modifier, which given its name, sounds like what AccessNode is supposed to be. The implementation doesn't need to change much though, we could still use an integer and parse the same way. Wdyt?