Fix data race on LoggerContext.size (#1038)

[seonwooj0810]

Fixes #1038

Root cause

LoggerContext.getLogger(String) creates each new logger under the monitor of its parent node (synchronized (logger)). Concurrent callers creating loggers below different parents therefore hold different locks, yet they all update the same counter via incSize(), which performed an unsynchronized size++. That read-modify-write races, so increments are lost under contention and size() reports fewer loggers than actually exist. This is exactly the ThreadSanitizer data race reported in the issue.

Change

Make the counter an AtomicInteger and use incrementAndGet() / get(), so the count is maintained atomically regardless of which parent monitor a thread happens to hold. No locking is added to the hot path.

Test evidence

Added LoggerContextTest#concurrentGetLoggerKeepsSizeConsistent: 16 threads each create 500 loggers under their own distinct parent (so their incSize() calls hold distinct monitors, maximising contention), then the test asserts size() matches the real logger count.

• Before the fix the test fails, e.g. expected: <8017> but was: <7970> (lost increments).
• After the fix it passes; the full LoggerContextTest (17 tests) is green.

Verification done: built and ran mvn -pl logback-classic -am -Dtest=LoggerContextTest test on the branch (all pass), and confirmed the new test fails on unpatched master.