Implement global configuration using configuration API

[delner]

To allow for better management of configuration options, this pull request implements global configuration options as a configuration object accessible via Datadog.configuration.

The configuration API remains backwards compatible, meaning Datadog.configure { |c| c.tracer options } and other configuration paradigms will continue to function. However, it provides a base for new options to be defined (or extracted from elsewhere). For example the following option could be defined in Datadog::Configuration::Settings:

option :debug, default: false

Then it can be set using:

Datadog.configure |c|
  c.debug = true
end

Or accessed using via Datadog.configuration.debug.

(Note this is just an example: debug option has not yet been defined this way.)

While implementing this feature, this pull request does a few ambitious things:

• Removes obsolete configuration API components (e.g. Configuration::Proxy, Contrib::Base, etc.)
• Promotes core configuration API components (e.g. Options) to Datadog::Configuration from Contrib
• Demotes integration specific configuration to Contrib (e.g. Registry) and the Contrib::Extensions module.
• Replaces Datadog::Configuration with Datadog::Configuration::Settings, which implements options just like integrations do.

[brettlangdon]

🔥 🔥 🔥

Nice, a lot of this looks like shuffling around existing classes? Looks that way, but not sure why the diff didn't pick them up as a file name?

[delner]

@brettlangdon Yeah, exactly. There's a lot of shuffling, and a few classes/modules had their responsibilities split and redistributed elsewhere: e.g. Datadog::Configuration doesn't define a registry anymore, Contrib::Extensions adds that back to Datadog::Configuration because registry is a Contrib component now. Almost all of the test logic is the same, except for a few places where obsolete configuration code was ripped out.

If there aren't any referential errors after this refactor (e.g. if I missed a constant name on a code path or something like that), then the only other risk posed by this re-shuffle would be if someone referenced these constant names directly elsewhere, which I think is low probability and out of scope of what's supported in our public API.

I will test this locally a bit more, make sure everything seems sane still.