Mitigation for bad logger implementation

[MEINDL Rupert]

Hello,

I would propose a small optimization regarding the logger handling for class org.opensaml.core.config.ConfigurationService:
Because of an bad behaving logger implementation behind SLF4j LoggerFactory.getLogger() we had a massive performance issue with getConfigurationProperties()/getLogger().
The bad behaving logger implementation was forced to rebuild the logger instance time and time again, with high CPU & memory impact.
To mitigate this problem we patched class org.opensaml.core.config.ConfigurationService the following way:

@@ -72,0 +73,4 @@ public class ConfigurationService {
+    private static ThreadLocal<Logger> loggers = ThreadLocal.withInitial(() -> {
+      return LoggerFactory.getLogger(ConfigurationService.class);
+    });
+    
@@ -228 +231 @@ public class ConfigurationService {
-        return LoggerFactory.getLogger(ConfigurationService.class);
+      return loggers.get();

This generates a logger instance only if necessary, helping a lot with bad behaving implementations behind SLF4j.
Our currently used OpenSAML Core Version is 3.3.1. OpenSAML is used not directly but called from third party libraries such as Apache CXF.

If this solution is acceptable, it would be nice if it can be merged into the 3.x branch.   

Best regards,
Rupert Meindl