Refactor StatusLogger to use precompiled Pattern constants

[kamilkrzywanski]

We should improve the implementation of StatusLogger by extracting all regular expressions used for property normalization and matching into clearly named, precompiled Pattern constants. This change would:

Avoid repeated calls to Pattern.compile(...), improving performance.
Increase readability and maintainability by clearly naming intent of regex patterns.

[vy]

We should improve the implementation of StatusLogger by extracting all regular expressions used for property normalization and matching into clearly named, precompiled Pattern constants.

Should we? Aren't these only used once during the Config singleton initialization? Would you mind sharing the performance problem you're having?

[ppkarwasz]

The normalization logic in StatusLogger only needs to support the five legacy constants listed below and their corresponding normalized forms. There's no need for complex logic or performance optimizations here — defining four simple lookup tables to map between the different formats should be sufficient.

Legacy Constant	Normalized Forms
log4j2.debug	Normal: log4j2.debug
	Env Var: LOG4J_DEBUG
	Log4j 3: log4j.debug
log4j2.status.entries	Normal: log4j2.statusEntries
	Env Var: LOG4J_STATUS_ENTRIES
	Log4j 3: log4j.statusLogger.statusEntries
log4j2.StatusLogger.level	Normal: log4j2.statusLoggerLevel
	Env Var: LOG4J_STATUS_LOGGER_LEVEL
	Log4j 3: log4j.statusLogger.level
log4j2.StatusLogger.dateFormat	Normal: log4j2.statusLoggerDateFormat
	Env Var: LOG4J_STATUS_LOGGER_DATE_FORMAT
	Log4j 3: log4j.statusLogger.dateFormat
log4j2.StatusLogger.dateFormatZone	Normal: log4j2.statusLoggerDateFormatZone
	Env Var: LOG4J_STATUS_LOGGER_DATE_FORMAT_ZONE
	Log4j 3: log4j.statusLogger.dateFormatZone