Follow up on #1480, which was addressed via #1730

While #1730 improves attribute detection a lot and made it less irritating, there is still more to do to improve this, especially in light of new attributes and attribute features having been added in recent PHP versions.

Think along the lines of:

• An attribute which could be applied to a few type of constructs to begin with can now be applied to another type of construct.
  How should this be reported ?
  For native PHP attributes, this is likely to lead to a Fatal Error on the PHP versions which didn't allow for the "new" construct yet, so I believe PHPCompatibility should detect and flag this - see: https://3v4l.org/4Ia45 and https://3v4l.org/D1I78
  However, on PHP versions on which the attribute didn't exist yet, the attribute will be silently ignored, independently of the location, so this is more complicated than just a straight testVersion check - we will probably need to check if testVersion includes PHP versions between the PHP version which introduced the attribute and the PHP version in which the "attribute targets" changed.
  This should only be handled for PHP native attributes.
• Userland attribute classes can (will) extend a PHP native attribute class, if only the base Attribute class.
  I believe the NewClasses sniff (and RemovedClasses once it becomes relevant) should flag use of PHP native attribute class names in all places (new ..., instanceof ..., ... extends ... etc) except when the attribute class name is used in an attribute.
  The use of the attribute class in an attribute should be handled separately by the NewAttributes sniff (or a related sniff) as this should be a warning, not an error and possibly should not be flagged at all.
• The NewAttributes sniff currently uses certain "groupings" for the error codes used to flag certain attributes.
  While these groupings make the sniff less irritating as one can choose to ignore a complete group of attributes, this can also result in the sniff ignoring too much, which is risky.
  This needs rethinking to allow for more targetted ignoring, while still being able to ignore certain groups of attributes.
  Also keep in mind attributes which already existed in one of the "groups" and were later introduced in PHP itself, confusing the sniff (and the end-user).
  We may need to consider having fully modular error codes (using the class name) and then having add-on rulesets to ignore attributes from certain tools ?
• There is also currently no tracking/flagging of attributes by PHPCompatibility based on the PHP version which introduced the attribute class, while this may actually be helpful (Flagging that a SensitiveParameter is unprotected on older PHP versions).