Reduce severity & verbosity of instrumentation ImportError (#1115)

[john-karp]

Description

In auto-instrumentation context, it is expected that many of the supported target libraries will not be present. Hence, it does not make sense to flood logs with ImportErrors for this expected scenario.

The existing workaround of having users set OTEL_PYTHON_DISABLED_INSTRUMENTATIONS to prevent this gets in the way of the ideal of "making instrumentation easy", because instead of allowing for instrumentation to be 'automatic', users then have to come up with (and maintain in the face of upstream changes) an explicit list of instrumentations to opt out of.

Fixes #1115

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• tox

Does This PR Require a Core Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been updated
• Documentation has been updated

[linux-foundation-easycla]

• ❌ The email address for the commit (1fd497e) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.