## Summary of changes

Rebuild and re-assign `MutableSettings` when dynamic config (remote or
config in code) changes.

## Reason for change

This is part of a general stack to extract the "mutable" configuration
from static config that is fixed for the lifetime of the app. In the
[previous PR](#7522) we
moved mutable settings to their own type, but otherwise left things
unchanged and just rebuilt everything whenever anything changes.

In this PR we move towards combining the dynamic/code configuration,
handling changes by _only_ rebuilding the `MutableSettings` (not
`TracerSettings`) and handling all the fallout that causes for
telemetry.

This is very much still a "stop gap"; we still rebuild everything
(_except_ the `TracerSettings` object) when these settings changes.

## Implementation details

- Create "global" config sources for dynamic settings and code settings
- There's actually a bug today where we clobber dynamic settings if we
change things in code because we're not storing the sources globally.
- When dynamic config or config in code changes
- Create a new `MutableSettings` object based only on dynamic sources
(with a fallback for the "static" values)
  - For config in code, we also check for changes to `ExporterSettings`
- If there's no discernable changes, bail out - no need to tear down the
world
- If there _are_ changes, Mutate `TracerSettings`, and do the normal
"reconfigure everything"
- Remove the (now unused `ImmutableDynamicSettingsTests`)

Note that there are technically some behaviour changes in this PR:
- `useDefaultSources: false` only ignores env vars etc for values that
can be set through code. Other settings will always use the default
sources.
- `StatsComutationEnabled` can not be _set_ via code.

## Test coverage

This is still all technically a "refactoring", so should be covered by
existing tests 🤞

## Other details


https://datadoghq.atlassian.net/browse/LANGPLAT-819

Part of a config stack
- #7522
- #7652
- #7525 👈
- #7530
- #7532
- #7543
- #7544