Logger context properties

[rgoers]

This implements the Properties Enhancement .

I still need to update the documentation in the manual, but I will do that in a separate PR.

This commit is quite large I suspect a lot of the changes are due to merging the spotless changes in from main, but this still hit a very large number of classes.

As a guide here are the major items:

1. PropertiesUtil was modified to a) stop doing most of the normalization junk b) support getting properties from JSON as well as properties, c) allow multiple properties/json files to be located during scanning, d) allow LoggerContext specific files to be located either in META-INF/log4j2.{contextName}.properties|json or META-INF/log4j2.context.properties|json.
2. Most PropertySources now extend ContextAwarePropertySource and support separating the properties into multiple Properties objects based on which context they belong to.
3. LoggerContext now has a reference to a PropertiesUtil.
4. System and Environment properties can apply at the system-wide level or LoggerContext scope. Properties in those files should follow the naming convention of "log4j2.{contextName}.{component}.{key}". For system-wide scope the context name is "*".
5. Maven doesn't support "" in a property name since the non-deprecated syntax has the property name as an XML element. As such, system properties may be defined without the log4j2., in which case they will be treated having system-wide scope.
6. Properties in context specific files can ONLY apply to that context so all properties in those files must leave off the "log4j2.{contextName} prefix.
7. All Log4j properties are defined as enums in classes that implement PropertyKey. Unfortunately @SetSystemProperty cannot use the enum so a static constant for each enum is also defined but is only used for that purpose.
8. PropertiesUtil now has a ThreadLocal that holds the LoggerContext's PropertiesUtil during configuration, thus allowing all that stuff to not need access to the LoggerContext or be injected with a PropertiesUtil (which almost certainly would create a circularity anyway). PropertiesUtil.getProperties() checks the ThreadLocal and uses that if it is not null.
9. Both LoggerContextFactory getContext methods and LoggerContext's reconfigure method set the ThreadLocal while configuration is occuring.
10. All tests and all classes using properties were modified to reference LoggingSystemPropertyKey (log4j-api) or Log4jPropertyKey (log4j-core).
11. A file named log4j2.propertyMapping.json can now be defined in any jar. This file contains property aliases for the new key names. This is only used when looking up keys, such as log4j.level, which it maps to StatusLogger.level. Note that this does not allow properties to be defined in files or as system properties with these names.

[ppkarwasz]

Shouldn't this be mostly in log4j-core?

[rgoers]

It is an enum. So I would need one in core and one in the API. I didn't think it was worth the effort.