[logback-dev] Better introspection into logging setup

[Durchholz, Joachim]

> Having this API as part of SLF4J would allow to have a JUL 
> bridge which is agnostic of the actual logging backing. But a 
> valid questions remains, if such API should be added to SLF4J 
> just because of the JUL bridge.

*Something* should be done considering that JUL is going to be around
for at least another decade, and that JUL kills performance if it's
configured with the root logger at Level.ALL.

I see two approaches:
1) Improve the JUL bridge so that it installs only loggers where the
SLF4J configuration wants one. This requires minimal access to the
backend's configuration.

The question is what to do.
Currently, I see two variants:
1) Improve the JUL bridge.
2) Improve the JUL bridge docs and tell people how to configure JUL so
that the JUL bridge performs well.

(Variant 2 seems doable to me. I think JUL bridge performance can be
returned to acceptable levels by
- configuring those third-party libs that use JUL via the JUL facilities
and
- configuring the SLF4J backend at Level.ALL for the logger namespace(s)
of said libs.
I wouldn't like to keep logging configuration in two separate files, and
I haven't tried it yet, but it could be done... the question is: what
approach would fit better with SLF4J? I can't answer that last
question.)