[Feature][Plugin] Datadog Incident Management integration

### Search before asking

- [x] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) and found no similar feature requirement.

### Use case

As an engineering leader using DevLake for DORA metrics, I want to ingest incidents from [Datadog Incident Management](https://docs.datadoghq.com/incident_response/incident_management/), so that change failure rate and time to restore service keep working after a team moves its on-call off PagerDuty and onto Datadog.

DevLake already supports PagerDuty, Opsgenie, Rootly and incident.io. Datadog is a common destination for teams consolidating monitoring, paging and incident response in one tool, and today those teams lose their incident source when they migrate. The only path left is the generic webhook plugin, which cannot carry severity history, detection timestamps or per-incident custom fields.

### Description

Datadog Incident Management exposes incidents through the public API (`/api/v2/incidents`,
paginated). Auth is the standard Datadog pair of an API key plus an application key,
against a site-specific host (`api.datadoghq.com`, `api.datadoghq.eu`, `api.us3.datadoghq.com`, …),
so the connection needs an endpoint or site field like other multi-region plugins.

Proposed plugin, modeled on `incidentio` and `rootly`:

- **Connection**: API key + application key + site/endpoint.
- **Scope**: incident types, analogous to the incident-type scope in the incident.io plugin.
A single organization-wide scope is the fallback for orgs that do not use incident types.
- **Entities**: incidents → domain `issues` with `type = INCIDENT` plus `incidents`.
Field mapping, verified against a production Datadog organization:

| Datadog | Domain |
|---|---|
| `public_id` (and `slug`, e.g. `IR-22`) | `issue_key` |
| `title` | `title` |
| `severity` (`SEV-1`…`SEV-5`, `UNKNOWN`) | `severity`, via a configurable mapping |
| `state` (`active` / `stable` / `resolved`) | `status`, `original_status` |
| `created` | `created_date` |
| `detected` | detection timestamp, for time to detect |
| `resolved` | `resolution_date`, `lead_time_minutes` |
| `customer_impacted`, `customer_impact_duration` | impact attributes |
| `url` | `url` |
| `is_test` | excluded from collection, like incident.io's test/tutorial incidents |

- **Custom fields**: Datadog incidents carry both default fields (`detection_method`,
`root_cause`, `services`, `teams`) and org-defined single-select, multi-select and
free-text fields. The plugin would collect these verbatim into the tool layer, and the
**scope config** would name which field maps onto `component` and which onto `severity`.
The same shape as the deployment-name pattern in the CircleCI scope config. This keeps
organization-specific vocabulary out of the plugin while making the fields usable for
change-failure attribution.

- No framework changes: the result feeds the existing DORA incident metrics.

**Out of scope** for a first PR: Datadog On-Call (schedules, pages, escalation policies),
monitors and alerts, and the Datadog DORA Metrics product.

We have mapped the fields above against our own production Datadog organization through
the API, and intend to implement the plugin in Go following the `incidentio` plugin layout
(`models/raw`, tool models with migration scripts, collector/extractor/converter tasks,
connection and scope APIs, e2e fixtures). Flagging the intent here first in case
maintainers want a different scope model or a different approach to the custom-field
mapping before we open the PR.

### Related issues

- #9023 - incident.io plugin, the closest precedent for scope and field mapping
- #8877 - Rootly plugin

### Are you willing to submit a PR?

- [x] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)