Refactor distros

[ocelotl]

This is a proposed refactoring of the distro mechanism. This PR is being opened so that the general approach can be reviewed, formal tests are still pending.

It implements solution B.

I found a few issues with the current distro mechanism:

1. There is redundancy between Distros and Configurators. Both perform configuration.
2. We require a Distro to be installed for opentelemtetry-instrumentation to work. I disagree with this because opentelemetry-instrumentation is something that is (at least partially) defined in the spec, Distro is not.
3. opentelemetry-instrumentation is directly coupled with Distro. Distro is a configuration mechanism that may not be preferred by the end user who may prefer to configure instead with a configuration file or a bash script, etc.

To solve these issues, this PR does the following, respectively:

1. I find Configurator to have the most representative name, so this PR removes Distro and refactors Configurator.
2. Having a Configurator is no longer required for opentelemetry-instrumentation to work.
3. opentelemetry-instrumentation now provides 2 entry points, one for plugins that are called before instrumentation and other for plugins that are called after instrumentation. Configurator is decoupled from opentelemetry-instrumentation by making it a plugin that is called before instrumentation.

opentelemetry-configurator provides an entry point by itself. In this way several Configurators can be registered and several can be called in the order defined by the environment variable OTEL_PYTHON_CONFIGURATORS if there is more than one Configurator installed.

Configurators are classes. This approach makes it possible to share common configuration by just inheriting from another one and calling super.

[lzchen]

As discussed in the SIG, @owais will be leading distro dicussions, closing this for now until we decide what direction we are heading for distros.