Improves support of log4j2.enableThreadlocals property

[ppkarwasz]

If the log4j2.enableThreadlocals property is set to false Log4j should clear all ThreadLocals from the calling thread before execution finishes.

The same rule should apply to user methods that correctly use the ThreadLocal interface. Code like this:

void method() {
    try {
        ThreadLocal.set("key", "newValue");
        ...
    } finally {
        ThreadLocal.remove("key");
    }
}

should perform a call to ThreadLocal#remove before exiting.

While the difference between threadLocal.remove() and threadLocal.set(null) is almost imperceptible in a classical threading model, when virtual threads are used the difference might be considerable.

This PR:

• Fixes all the ThreadContextMap and ThreadContextStack implementations (except GarbageFreeSortedArrayThreadContextMap) so that the context map/stack is cleared if the map/stack is empty.
• Modifies the ThreadLocals used to detect recursion to call ThreadLocal#remove when the recursion counter reaches 0.
• Fixes other ThreadLocal used for object pooling to respect the log4j2.enableThreadlocals property.

Remark: This PR does not address LOG4J-2753 that will be fixed in another PR.

Part of #2525.

[vy]

Missing ENABLE_THREADLOCALS checks

In several places, I see TL#remove() with only a ifEmpty() check. That is, ENABLE_THREADLOCALS is not taken into account. Why?

Performance-related changes without any empirical evidence

The PR description states the following:

While the difference between remove() and set(null) is almost imperceptible in a classical threading model, when virtual threads are used the difference MIGHT BE considerable.

This PR removes 94 and adds 425 LoC. Have we evaluated the assumption using benchmarks? It might be true that we will be shaving off some bytes from the thread stack, but aren't we also introducing an extra overhead since TLs need to be allocated again and again each time?

[vy]

Shouldn't this be null if !Constants.ENABLE_THREADLOCALS?