Fix properties configuration support for per-logger properties

[ramanathan1504]

Fixes #4024

Summary

This PR fixes a bug where custom logger-level properties (e.g., logger.log4j.property.type = Property) were silently ignored and dropped when configuring Log4j 2 using a .properties file.

Changes

• Enabled Nested Parsing: Passed logger, root logger, appender, and filter builders through processRemainingProperties to recursively parse nested custom properties.
• Prefix-Flattening Logic: Added a prefix-flattening loop in createLogger and createAppender to correctly resolve names and flatten nested keys for dotted prefixes.
• Duplicate Discarding: Updated parsing loops to return null and safely ignore invalid duplicate nameless configurations created by Log4j's dot-split prefix partitioning.
• Bypassed Empty Keys & Cleanup: Updated processRemainingProperties to safely bypass empty property names ("") and added loops to clear processed "appenderRef" and "filter" keys to prevent duplicate parsing.

Verification

• Updated PropertiesConfigurationTest#testPropertiesConfiguration to verify that custom properties are successfully loaded on both root and custom loggers.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[vy]

.properties logger parsing drops leftover property.* keys because createLogger/createRootLogger do not pass remaining properties through processRemainingProperties. @ppkarwasz in #4024 suggests to forward remaining logger properties like appenders already do.

1. Blocker: the PR changes validation semantics. Existing code throws for missing appender/filter/logger essentials; the PR returns null instead for appenders, filters, and loggers. That silently hides malformed configs and nested filters can still hit componentBuilder.add(createFilter(...)) without a null check. This is unrelated to #4024.

2. Blocker: the prefix-flattening logic is too heuristic. It scans for any *.name and rewrites the properties map in createAppender/createLogger. That can misinterpret nested component names as appender/logger names. partitionOnCommonPrefixes already gives the right structure for logger.foo.property.*, so this machinery should not be needed.

3. Regression risk: named logger levels stop using Strings.trimToNull; existing tests indicate trailing spaces on logger levels are intentional to support.

4. Borrowable pieces: the test assertions checking getRootLogger().getPropertyList() and named logger getPropertyList() are useful. Also, the PR notices the empty "" shorthand key must not be fed into processRemainingProperties; I’d handle that locally with properties.remove(""), not by changing the generic parser broadly.

I recommend to keep appender/filter parsing and validation unchanged; in createLogger and createRootLogger, consume the shorthand "" key, add refs/filters as today, then return processRemainingProperties(loggerBuilder, properties). Add focused tests for root logger properties, named logger properties, shorthand logger syntax, and preservation of malformed-config failures.