Componentize the remaining integration extensions (2nd part)

[reyang]

This PR follows the approach in #535 for the remaining extensions.
This is part of the effort for #445.

1. Reverted opencensus/trace/config_integration.py (which has been changed in Componentize the remaining integration extensions (1st part) #535) back since all the extensions are now under the same namespace.
2. Put test_utils.py under tests/unit/common.
3. Abandoned the opencensus/trace/ext folder.
4. Updated CHANGELOG.md.

[reyang]

@c24t I wish to know your opinion on this.

This "config integration" seems to be introduced for:

1. Frameworks such like Django which prefers configuration.
2. Convenience, e.g. having settings.py file (or even environment variable) which can be updated easily.

From dependency perspective, this is like "reflection", the core package is "depending" on contrib packages.

[reyang]

I would prefer to keep this feature, but refactor in the following way:

1. remove hard-coded integration names.
2. scan opencensus.ext namespace, try to import the extensions.
3. log warning if module not found.

[c24t]

That sounds like a good plan to me, although scanning installed packages may introduce some problems. Another complicating factor is that not every integration implements trace.trace_integration.

[reyang]

Here we don't follow the alphabetic order since ext-google-cloud-clientlibs has dependency on ext-grpc and ext-requests.
Ideally we don't want to maintain the order here, just having someting like "install all the packages under contrib, let pip figure out the dependency, resolve package dependency from contrib folder before consulting PyPI". Currently I haven't figured out how to do this.

[c24t]

Can you remove wrapt from setup.py now that requests is out in its own package?

[c24t]

This LGTM, although we may need to revisit the maximum versions for contrib packages as we update the library. Glad to see all these packages moved!

[reyang]

Can you remove wrapt from setup.py now that requests is out in its own package?

Yep! I'll do the clean up in my next PR (clean up dependencies, move the samples).