`ClassLoaderContextSelector` should create a separate context per classloader

The `ClassLoaderContextSelector#locateContext` currently implements the following logic:

https://github.com/apache/logging-log4j2/blob/f05864d4acf4198ec164e8ddfc2e325ffde21877/log4j-core/src/main/java/org/apache/logging/log4j/core/selector/ClassLoaderContextSelector.java#L189-L221

If the initial [`ContextSelector#getContext`](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/selector/ContextSelector.html) call does not provide a `configLocation` parameter and there is already a logger context associated to an ancestor of the `loader` classloader, **no new** context is created and the logger context of the ancestor is returned.

While this might be a feature to minimize the number of logger contexts, IMHO it should be **optional** and the default behavior should be to create a different logger context per classloader.

This behavior causes #1430 and the problems in #2311.

Start in log4j-core/src/main/java/org/apache/logging/log4j/core/selector/ClassLoaderContextSelector.java, at locateContext and the linked ContextSelector#getContext behavior. Review the cases described in #1430 and #2311, then determine how the default and optional ancestor-context behavior should be represented. Done means the classloader context behavior matches the chosen default and option, with the affected cases verified.

Written by the indexing model from the issue text.