KQL Support

My team comes from Azure Data Explorer / Microsoft Sentinel / Log Analytics, where
KQL (Kusto Query Language) is the native query language. Our analysts and SREs think
in KQL's pipe-based flow (source | where ... | summarize ... | project ...), and we
have a large library of saved queries, detections, and dashboards written in it.

Quickwit today exposes its own Lucene-style query mini-language and an
Elasticsearch-compatible DSL. Both are great for full-text filtering, but neither
maps cleanly onto the multi-stage transform-and-aggregate workflow KQL makes natural.
Porting existing KQL assets to Quickwit means rewriting everything by hand, which is a
major blocker to adopting Quickwit as a log/trace backend for teams already fluent in KQL.

Describe the solution you'd like
First-class KQL support, exposed as an additional query language (e.g. a
query_language=kql parameter on the existing search endpoints, or a dedicated
/kql endpoint) that parses KQL and translates it into Quickwit's internal
query + aggregation execution.

A useful initial subset, in rough priority order:

• Filtering: where, search, time-range predicates
• Shaping: project, project-away, extend, rename
• Aggregation: summarize with count(), sum(), avg(), min()/max(),
  dcount(), and bin() for time bucketing — these map onto Quickwit's existing
  metric/bucket aggregations
• Ordering & limiting: sort/order by, take/limit, top
• String/scalar functions and case/iff as a later phase

Out-of-scope clauses (join, mv-expand, user-defined functions, etc.) could return
a clear "unsupported operator" error rather than silently misbehaving.

Example translations (KQL on the left, the Quickwit operation it would lower to on the right):

1. Errors bucketed over time

The issue names the existing search endpoints, a possible /kql endpoint, and Quickwit's internal query and aggregation execution, but no files or tests. Start by tracing the existing search request path and aggregation support; done would mean a defined KQL subset translates correctly and unsupported operators return clear errors.