[java] Improve naming conventions rules

[oowekyala]

I thought about my former gitter comments and would like to begin working on it. This is an implementation plan, but of course anyone should feel free to chime in

The goal is to make the naming conventions rules much more granular and configurable. Our current rules are

• MethodNamingConventions, which isn't configurable at all
• ClassNamingConventions, same thing
• GenericsNaming, same thing
• VariableNamingConventions, which uses a weird mix of properties which are confusing and have limited practical use

I'm proposing to change these in the following way (probably one PR per item):

• (PR [core] Add new regex property type #975) Create a RegexProperty property type...
• (PR [java] Make ClassNamingConventions configurable #1007) ... and use it to make ClassNamingConventions...
• (PR [java] Improve method naming conventions rule #1040) ... and MethodNamingConventions configurable. The goal is to be able to configure a different pattern for enum, annotation, abstract classes, static methods, etc
• (PR [java] Add FormalParameterNamingConventions and LocalVariableNamingConventions #1214) Split VariableNamingConventions into three new rules: LocalVariableNamingConventions, FormalParameterNamingConventions, ...
• (PR [java] Add rule for field naming conventions #1296)... and FieldNamingConventions. For each of those, use regex properties to customise patterns for eg constants (public static final fields), final fields, enum constants, lambda parameters, etc.
• [java] Fix #972: Add a new rule TypeParameterNamingConventions #5922
  • Rename GenericsNaming to TypeParameterNamingConventions and provide configurability as well

Rule deprecation

The following rules become special cases of the more general new rules

• AbstractNaming -> superseded by ClassNamingConventions
• MIsLeadingVariableName -> superseded by LocalVariableNamingConventions and MethodParameterNamingConventions
• AvoidPrefixingMethodParameters -> superseded by MethodParameterNamingConventions
• SuspiciousConstantFieldName -> this one looks backwards to me, and is superseded by FieldNamingConventions anyway

Possibly also

• ShortVariable and LongVariable
  • see [java] Merge ShortVariable and LongVariable into LocalVariableNamingConventions and FormalParameterNamingConventions #5950
• ShortMethodName
  • see [java] Merge ShortMethodName into MethodNamingConventions #5952
• ShortClassName
  • see [java] Merge ShortClassName into ClassNamingConventions #5951

[oowekyala]

We could also introduce a new RangeProperty, that allows to set a range for the acceptable length of eg method, or variable names. This would be more concise than having a minimumLength and maximumLength property. The updated rules could then supersede ShortVariable, LongVariable, ShortClassName, and ShortMethodName cleanly. They would supersede them anyway, since you can use regex to set min or max length, but it would make the regexes harder to read. Related to #720

[jsotuyod]

I believe we should address #953 as part of the VariableNamingConventions refactor