…ustom spans

Adds `datadog-ci trace from-otel <file.json>`, which reads an OpenTelemetry
OTLP/JSON trace file (e.g. from an OTel Collector `file` exporter, otel-cli, or a
tool's built-in exporter) and reports each span to Datadog as a CI Visibility
custom span. Addresses the request in DataDog#2385.

Hierarchy uses the same `span_id`/`parent_id` convention that `trace span`
adopts in DataDog#2397: each span gets a `span_id` derived from the OTLP file, child
spans set `parent_id` to their parent's `span_id`, and root spans attach to the
CI job/step. The originating OTel trace id is preserved as an `otel.trace_id`
tag for correlation. ID normalization accepts both hex and base64 encodings, and
enums/timestamps accept both the numeric and proto3 string forms the Go
Collector emits.

- Base-only command under the existing `trace` scope; gated at runtime via
  `DD_BETA_COMMANDS_ENABLED` (the scope is non-beta, so scope-level gating can't
  express it).
- No new dependencies: OTLP wire types are a small local subset (the SDK doesn't
  export them publicly and would drag in the transformer chain).
- Reuses `CustomSpanCommand` for API-key/CI/git tag assembly and the intake POST;
  adds an additive `executeReportCustomSpans` batch method and threads an optional
  `parentId` through `executeReportCustomSpan` (single-span payload and tag/measure
  precedence unchanged). OTel attributes sit below git/CI context tags so they
  cannot clobber authoritative values.
- `--max-spans` (default 1000) caps volume; malformed input yields a clean exit 1.
- Two behaviors intentionally match the existing `trace span`: `DD_TAGS` takes
  precedence over `--tags`, and a failed send is logged but does not fail the
  command.

Co-Authored-By: Claude Opus 4.8 <[email protected]>