Is your feature request related to a problem? Please describe.
As pointed out in #6131 rule properties based on enums are implemented in different ways. They should be implemented in a consistent way.

The Enum Property Builder uses a "labelMaker" function, that is used to convert the enum constant name into a string for usage in the ruleset xml.
Some use toString (net.sourceforge.pmd.lang.java.rule.codestyle.ConfusingTernaryRule.NullCheckBranch), some use a custom adhoc mapping (net.sourceforge.pmd.lang.java.rule.codestyle.ModifierOrderRule.TypeAnnotationPosition, net.sourceforge.pmd.lang.java.rule.documentation.CommentRequiredRule.CommentRequirement) and other use camel case conversion via CaseConvention.CAMEL_CASE (net.sourceforge.pmd.lang.java.rule.bestpractices.AvoidReassigningLoopVariablesRule.ForeachReassignOption).

Ideally, we would use the same notation for all enum properties.

Describe the solution you'd like

• Make it programmatically impossible to do the wrong thing: have only one overloaded method net.sourceforge.pmd.properties.PropertyFactory#enumProperty
• Other methods to create a enum property should be deprecated
• We need a solution for backwards compatibility - we might find the old notations used in rulesets, so we should still be able to read it. Ideally issuing a deprecation warning
• When generating the rule docs, we should generate a possible values for an enum property. This is a smaller task than [doc] Produce example configs for rule properties #4297 but would still be helpful I think.
• The notation and convention should be
  • enum values in Java follow the usual naming convention to be SCREAMING_SNAKE_CASE
  • enum values, that are used for rule properties, should use the "camelCase" naming convention
  • the values in ruleset xml should use the same notation - no extra conversion (Enum::name() and Enum::valueOf)

Describe alternatives you've considered

• none considered

Additional context

• this will affect compatibility...