Fix NoMethodError when running Datadog.configure after only requiri…

…ng core

The fix in #1998, specifically in
2e5d1ee
broke using `datadog/core` directly without `require 'ddtrace'`.

For instance:

```
bundle exec ruby -e "require 'datadog/core'; Datadog.configure { }"
Traceback (most recent call last):
  9: from -e:1:in `<main>'
  8: from .../lib/datadog/core/configuration.rb:89:in `configure'
  7: from .../lib/datadog/core/configuration.rb:223:in `safely_synchronize'
  6: from .../lib/datadog/core/configuration.rb:223:in `synchronize'
  5: from .../lib/datadog/core/configuration.rb:225:in `block in safely_synchronize'
  4: from .../lib/datadog/core/configuration.rb:94:in `block in configure'
  3: from .../lib/datadog/core/configuration.rb:243:in `build_components'
  2: from .../lib/datadog/core/configuration.rb:243:in `new'
  1: from .../lib/datadog/core/configuration/components.rb:345:in `initialize'
.../lib/datadog/core/configuration/components.rb:202:in `build_profiler': undefined method `supported?' for Datadog::Profiling:Module (NoMethodError)
```

As a workaround, I've added a `require 'datadog/profiling'` in
`build_profiler`: this avoids re-adding the circular dependency issue,
but fixes this use-case.

Additionally, I've made is such that profiling is only loaded if it
is enabled, which means that customers not using it will not need to
load it, which is a nice bonus vs what we did prior to #1998.

lib/datadog/core/configuration/components.rb

@@ -179,7 +179,27 @@ def writer_update_priority_sampler_rates_callback(sampler)
           end
 
           def build_profiler(settings, agent_settings, tracer)
-            return unless Profiling.supported? && settings.profiling.enabled
+            return unless settings.profiling.enabled
+
+            # Workaround for weird dependency direction: the Core::Configuration::Components class currently has a
+            # dependency on individual products, in this case the Profiler.
+            # (Note "currently": in the future we want to change this so core classes don't depend on specific products)
+            #
+            # If the current file included a `require 'datadog/profiler'` at its beginning, we would generate circular
+            # requires when used from profiling:
+            #
+            # datadog/profiling
+            #     └─requires─> datadog/core
+            #                      └─requires─> datadog/core/configuration/components
+            #                                       └─requires─> datadog/profiling       # Loop!
+            #
+            # ...thus in #1998 we removed such a require.
+            #
+            # On the other hand, if datadog/core is loaded by a different product and no general `require 'ddtrace'` is
+            # done, then profiling may not be loaded, and thus to avoid this issue we do a require here (which is a
+            # no-op if profiling is already loaded).
+            require 'datadog/profiling'
+            return unless Profiling.supported?
 
             unless defined?(Profiling::Tasks::Setup)
               # In #1545 a user reported a NameError due to this constant being uninitialized