[WIP] Eager tracer initialization

[marcotc]

This PR removes lazy initialization of internal ddtrace components, replacing them with a predictable, eager initialization.

There's also a large refactor of the tracer global life cycle management, as our tests suite went bananas with the change: I wasn't able to fix our tests without proper life cycle management in-between tests.

There's no more stateful tracer data stored in the global Datadog module: all stateful data is encapsulated in a Runtime class instance.

The global Datadog module holds one instance of the Runtime: creating a new Runtime initializes the tracer; destroying the Runtime shuts down the tracer.

In-between test runs, the Runtime is discarded and created anew. There is not more state that can be leaked.

A production application initializes the Runtime once, at require 'ddtrace' time, and destroys it at at_exit time.

[marcotc]

@ivoanjo thanks for taking a look at this still draft PR.

I've talked to @delner last month about it as well, and there's quite a bit of stuff that works well here, but also a lot of work that will spawn from this: more clear separation for per-product lifecycle management and dependencies.

I'll break this down into smaller, digestible parts. Some will be easy to implement without much change, other will likely won't be done by the time I finish the main goal of removing lazy initialization.

[ivoanjo]

Sounds good! Looking forward to a cleaner design, this is really a crazy balancing act, so thanks for tackling it :)