Is your feature request related to a problem? Please describe.

Currently violations have a couple of methods like getPackageName, getMethodName:

These are mostly Java-specific and the way this data is filled-in is very awkward: we have a JavaRuleViolation subclass of RuleViolation that initializes the fields in its constructor. To create a JavaRuleViolation we need a RuleViolationFactory instance which is mostly redundant.

The problems with this design are

• We need a subclass of ParametricRuleViolation even though the superclass already has all fields
• We need the interface RuleViolationFactory and language-specific implementations even though they're only used to call the correct constructor for the violation subclass
• The attributes cannot be extended easily by other languages than Java
• The attributes are meaningless in some languages, eg XML flavours

Describe the solution you'd like

• Refactor these "extra attributes" to be exposed through a method Map<String, String> getAdditionalInfo() in RuleViolation. Standard keys like PACKAGE_NAME and CLASS_NAME can be exposed as constants in the RuleViolation interface.
• Create a new interface ViolationDecorator whose job is to add extra attributes to the map. Use that in RuleContext when we create a new violation
• Remove the RuleViolation subclasses and finally remove RuleViolationFactory.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

• Part of PMD 7 PMD 7 Tracking Issue #3898
• The new interface would be part of the nspmd.reporting package, like ViolationSuppressor
• The extra attributes are constrained to be string-valued because we need to serialize them to write them into the violation cache.