Datadog metrics adapter implementation using DogStatsD protocol.

This adapter integrates with Datadog (https://datadoghq.com) for production metrics
collection via the DogStatsD UDP protocol. It implements all metrics protocols to
provide comprehensive metrics capabilities that integrate with Datadog's platform.

Features:
- DogStatsD UDP protocol implementation
- Counter, gauge, histogram, and timing metrics
- Tag merging (global, metric default, call-specific)
- Sampling support for performance optimization
- Runtime metric enable/disable for performance tuning
- In-memory metric registry and value tracking
- Injectable send function for testability

Configuration:
The adapter requires a host and service name, optionally accepting:
- Port (default 8125)
- Global tags applied to all metrics
- Sample rate for counters and histograms
- Maximum packet size (UDP MTU considerations)
- Origin detection for container environments

Example:
(def datadog-metrics
  (create-datadog-metrics-components
    {:provider :datadog-statsd
     :host "localhost"
     :port 8125
     :service "my-service"
     :environment "production"
     :global-tags {:team "backend" :version "1.0.0"}
     :sample-rate 0.1
     :max-packet-size 1432}))

No-op metrics adapter that safely ignores all metrics operations.

This adapter implements all metrics protocols but performs no actual metric
collection, making it safe for feature modules to use metrics protocols even
when metrics collection is disabled or not configured.

OpenTelemetry OTLP metrics adapter: bridges the Wagoe metrics ports onto
OpenTelemetry instruments and pushes them over OTLP/HTTP (protobuf) to any
OTel collector (SigNoz, Grafana, Datadog-via-OTel, …). No backend-specific
code — only the endpoint changes.

Metric-type mapping onto OTel instruments:
  counter   -> LongCounter    (.add)
  gauge     -> DoubleGauge    (.set)
  histogram -> DoubleHistogram(.record)
  summary   -> DoubleHistogram(.record)   ; OTel has no summary type

Export is push-based (a PeriodicMetricReader flushes to the collector), so the
`IMetricsExporter` local-render methods are not meaningful here: `export-*`
throw, `flush!` forces an OTLP flush, `get-metric-values`/`reset-metrics!` are
inert. Transport is OTLP/HTTP protobuf via okhttp (gRPC is not bundled).

Pure-Clojure Prometheus metrics adapter.

An in-memory metric registry that renders the Prometheus text exposition
format (https://prometheus.io/docs/instrumenting/exposition_formats/).
It implements all four metrics protocols
(IMetricsRegistry, IMetricsEmitter, IMetricsExporter, IMetricsConfig)
in a single component backed by one Clojure atom, so it is safe for
concurrent use via `swap!`.

No external Prometheus client dependency is used — the exposition text is
produced by this namespace directly.

Sanitization + collisions (BOU-207): metric/label names are sanitized to valid
Prometheus identifiers. Post-sanitization COLLISIONS are handled so the output
stays valid:
- Metric names: if a later registration sanitizes to the same name as an
  already-registered different key (e.g. :http.requests then :http-requests,
  both -> http_requests), the later one is logged and IGNORED — the first
  registration wins (no duplicate `# TYPE` line).
- Label keys within a series: keys that sanitize to the same label name are
  de-duplicated deterministically at render (the lexicographically-first
  [name value] pair wins), so no duplicate label appears in a series.

Series identity
---------------
Each metric value is keyed by (metric-name, label-set), where the label-set
is the merge of the registry default tags, the metric's registration tags,
and any per-call tags. Distinct label-sets are therefore distinct series.

Metric storage
--------------
- counter : {label-set -> numeric total}
- gauge   : {label-set -> numeric value (last write wins)}
- histogram: {label-set -> {:counts {bucket -> n} :inf n :sum s :count c}}
            (per-bucket non-cumulative counts; cumulative counts are computed
             at export time)
- summary : {label-set -> {:sum s :count c}}  — quantiles are NOT tracked;
            only the `_sum`/`_count` pair is emitted (see note below).

Simplifications
---------------
- Summary quantiles are not computed. A summary emits only `_sum` and
  `_count`, which is a valid (if minimal) Prometheus summary exposition.
- Metric names are emitted as-is (assumed already valid Prometheus names).