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

[ppkarwasz]

Instead of adding a modernized version of o.a.l.l.jul.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 — a long-standing and likely unresolvable limitation in the JDK that prevents flexible replacement of the LogManager.