Add a new EnumNamingStrategy SPI which can be used for customising the way enums are matched by name.
It is similar to the AccessorNamingStrategy such that it allows implementors to provide a custom way of defining a property.
Related to #796, #1220, #1789 and #1667
Add a new custom EnumTransformationStrategy SPI which can be used for providing custom way of name based mapping for enums.
Add 4 out of the box transformation strategies:
* prefix - add a prefix to the name based enum mapping
* stripPrefix - remove a prefix from the name based enum mapping
* suffix - add a suffix to the name based enum mapping
* stripSuffix - remove a suffix from the name based enum mapping
This can be achieved by using the new `EnumMapping`
e.g.
Add suffix `_TYPE` to all enums:
`@EnumMapping(nameTransformationStrategy = "suffix", configuration = "_TYPE")`
With this it would be possible to achieve what is needed in #796, #1220, #1789.
By default the constructor argument names are used to extract the target properties.
If a constructor is annotated with an annotation named `@ConstructorProperties` (from any package) then it would be used to extract the target properties.
If a mapping target has a parameterless empty constructor it would be used to instantiate the target.
When there are multiple constructors then an annotation named `@Default` (from any package) can be used to mark a constructor that should be used by default when instantiating the target.
Supports mapping into Java 14 Records and Kotlin data classes out of the box
Disable one test in GenericsHierarchyTest for Eclipse on Java 8 due to a bug in the Tycho compiler.
Disable freeBuilder integration test for Eclipse since there are some problems in the second round of annotation processing (no ModelElementProcessor(s) are found)
We need to treat the import of the decoratorType specially when it is nested.
Calling addIfImportRequired is not the most correct approach since it would
lead to checking if the type is to be imported and that would be false
since the Decorator is a nested class within the Mapper.
However, when generating the Decorator this is not needed, because the Decorator is a top level class itself
In a nutshell creating the Decorator should have its own ProcessorContext, but it doesn't
Adapt checkstyle configuration with new changes:
* Move cacheFile to Checker module
* Move LineLength to Checker module
* Use SuppressWithPlainTextCommentFilter
remove unnecessary generic types for collection,
replace numbers months on Calendar constants,
remove unnecessary exceptions from signature test methods
