Share one query language contract

[zzylol]

Why

The backend defined three query-language enums: one in shared configuration, one in control-plane request types, and one in QueryPlan. Their variant sets had already drifted, so adding MetricsQL or ClickHouse support required parallel edits and conversions.

Before this PR

Legacy configuration recognized only a lowercase Rust promql variant, control-plane request DTOs defined PromQL, and executable query plans separately defined PromQl, MetricsQl, and ClickHouseSql.

After this PR

asap_types::QueryLanguage is the single backend contract and is re-exported by request and query-plan modules. It covers PromQL, MetricsQL, and ClickHouse SQL with one stable snake-case serde representation. CLI aliases continue to accept PROMQL and promql. Legacy aggregation parsing now handles both time-series languages and derives explicit table/value-column inputs for ClickHouse SQL.

Example

A QueryPlanEntry, adapter configuration, and control-plane request now carry the same QueryLanguage::MetricsQl value instead of crossing DTO-specific enum boundaries.

Verification

• cargo check --workspace --all-targets
• cargo test -p control_plane --lib query_plan::tests (5 passed)
• cargo test -p control_plane --lib types_v2::tests (6 passed)
• cargo test -p asap_types aggregation_config::tests (5 passed)
• git diff --check

Depends on #575.

ClickHouse migration surface: use asap_types::QueryLanguage::ClickHouseSql through the existing control_plane::query_plan re-export; do not add a language-specific enum or catalog.