Add a universal `j.u.l.LogManager` implementation

Instead of adding a modernized version of [`o.a.l.l.jul.LogManager`](https://logging.apache.org/log4j/2.x/log4j-jul.html#bridge-logmanager), we could create a **universal** `j.u.l.LogManager` implementation — as discussed in qos-ch/slf4j#429. This implementation would forward log events from both `j.u.l.Logger` and `j.l.System.Logger` to at least the **Log4j API** and **SLF4J**, depending on what's available at runtime.

### ✅ Benefits

- **Broader interoperability**
Logback users would benefit directly, as there is currently no `j.u.l.LogManager` implementation that routes log events to SLF4J directly. Today, they must route through Log4j as an intermediary.

- **Modular and runtime-flexible**
A `ServiceLoader`-based design would allow applications and containers to **hardcode the LogManager implementation** in their initialization scripts or main class, while still letting users decide which logging backend (JUL, Log4j Core, Logback, etc.) to plug in.

- **Practical workaround for JDK limitations**
This approach effectively serves as a **community-driven workaround for [JDK-8262741](https://bugs.openjdk.org/browse/JDK-8262741)** — a long-standing and likely unresolvable limitation in the JDK that prevents flexible replacement of the `LogManager`.