Create a standalone artifact for non-internal test fixtures

The current `log4j-core-test` module includes a variety of test fixtures primarily designed to test Log4j Core itself and its internal plugins. These fixtures assume that:

* Static loggers (other than `StatusLogger`) are absent from the code under test.
* A new `LoggerContext` can be created per test case.
* Loggers are created by the test cases, not the code under test.

This model works well for testing Log4j itself but breaks down in the context of third-party libraries and applications, where:

* Loggers are typically declared as `static final` fields.
* Logger initialization might happen before the test setup, making it impractical to substitute a different `LoggerContext` or logger instance at runtime.

As a result, most test fixtures in `log4j-core-test` are not reusable outside of Log4j’s own testing. The only widely useful component is `ListAppender`, which depends solely on Log4j Core. However, to use just `ListAppender`, developers must still depend on the entire `log4j-core-test` module—bringing in unnecessary dependencies and potential conflicts that often need to be manually excluded.

### Proposal

To improve the usability and modularity of Log4j test support for third-party projects:

1. **Extract `ListAppender` into a new, standalone artifact**
This artifact would:

* Be explicitly intended for use by external libraries and applications in testing scenarios.
* Only include minimal and broadly useful test utilities like `ListAppender`.
* Have the same backward compatibility guarantees as Log4j Core itself.

2. **Evaluate and incorporate improvements from past community feedback**
In particular, we should revisit insights from this [dev@logging thread](https://lists.apache.org/thread/3n9xqc132pm49w3m67zm6wnjfw6yphkq)
Specifically, we should:

* Address concerns around using `ListAppender` in parallel test executions.
* Improve thread-safety and isolation for better test reliability.

### Benefits

Although testing log output in unit tests is sometimes seen as excessive or even bad practice, there are specific cases where it is both justified and valuable:

* **Audit Logging Compliance**
Verifying that audit logs are emitted correctly is crucial in systems where traceability and accountability are required. This aligns with one of the core purposes of Log4j Core itself.

* **Capturing Operational Details Not Exposed to Users**
In many systems, user-facing error messages are intentionally vague for security or UX reasons. Logs often carry the detailed context needed for debugging, so it's useful to ensure those details are reliably recorded.

* **Monitoring Failures in Background Threads**
Failures in asynchronous or background threads often can't propagate to the main execution flow. Logging may be the *only* way these failures surface, making it essential to validate they’re captured appropriately.

To support these use cases effectively, it's important to provide users with a lightweight, purpose-built artifact focused solely on general logging test utilities. This avoids the complexity and overhead of `log4j-core-test`, which includes many features intended only for internal testing of Log4j Core itself.

Start by reviewing the log4j-core-test module and its ListAppender fixture, then read the linked dev@logging thread for prior feedback. Done means a standalone artifact provides the reusable fixture without the broader test-module dependencies and addresses parallel execution, thread-safety, and isolation concerns.

Written by the indexing model from the issue text.