Consider moving `LoggingHandler` out of the SDK and into an instrumentation

[aabmass]

LoggingHandler is a Python stdlib logging.Handler implementation that bridges stdlib logging to the Logs SDK.

Some reasoning:

• It is not something that is specified in the SDK
• Will need to follow SDK versioning
• As a separate package, users could simply uninstall it if they don't want logging logs captured at all (or use OTEL_PYTHON_DISABLED_INSTRUMENTATIONS).
• Consider that opentelemetry-instrumentation-urllib is separate even though urllib is part the python standard library.
• There are other logging APIs like structlog.

Arguments against:

• A high percentage of users want to set it and forget it and this adds an extra step

[xrmx]

We already have a logging instrumentation btw.

The argument against is valid for every other instrumentation 😅

[aabmass]

The argument against is valid for every other instrumentation 😅

True just trying to present some counterargument.

Existing logging instrumentation confusion aside, are you in favor or against moving LoggingHandler out of the SDK?

[lzchen]

I believe java already uses this convention for different logging libraries. Happy to discuss this in the SIG @aabmass

[xrmx]

The argument against is valid for every other instrumentation 😅

True just trying to present some counterargument.

Existing logging instrumentation confusion aside, are you in favor or against moving LoggingHandler out of the SDK?

I'm in favor, it would be a lot less confusing to me :)