Extended PromQL grammar to support optional time-range parameters
before the query expression. Parameters are specified as
space-separated name-value pairs (e.g., "step 5m")
and can appear in any order.
Currently only literals and field references are allowed, expressions
such as (now() - 1h) are not supported.

The query itself is enclosed in parentheses to enable future assignment
syntax like "promql x=(...)" while avoiding ambiguity.

Implementation details:
- Introduced two-mode lexer architecture:
- PROMQL_PARAMS_MODE: Captures parameter name-value pairs using
  generic identifiers (PROMQL_UNQUOTED_IDENTIFIER or
  QUOTED_IDENTIFIER)
- PROMQL_QUERY_MODE: Captures query text with depth tracking for
  balanced parentheses. Skipping then ends up with ambiguitities
  error when dealing with nested queries or having promql inside
  explain
- Parser uses recursive rule (promqlQueryPart) to handle nested
  parentheses in PromQL expressions without limiting nesting depth
- Added depth tracking methods in LexerConfig
  (incPromqlDepth, decPromqlDepth, resetPromqlDepth, isPromqlQuery)
  to distinguish between query-closing and query-internal
  parentheses
- Query text extraction preserves original source verbatim using parse
  tree token positions
Examples:
promql step 5m (rate(http_requests[5m]))
promql time now (up {job="api"})
promql start ?start_time step ?interval (sum(network_bytes))

This is to align more closely with the query parameter names for the prometheus range_query API.

This is to avoid ambiguity with org.elasticsearch.xpack.esql.parser.LogicalPlanBuilder

Previously Vector operations were defined as Expressions which didn't
match the actual semantics not the rest of the parsing infra. This has
now been addressed by making the nodes LogicalPlans.

)

Remove GrammarTests in favor of PromqlAstTests to test not just the
grammar but also the semantic validation of the queries, especially
as the latter includes the former.

The invalid tests are currently passing, but there are still some valid
tests that are failing, likely due to incorrect AST assembly.

Refactor Subquery from Expression into LogicalPlan. Duration parsing is
wip.

Unify the logic for arithmetics between scalars alone and scalars and
time durations

To simplify date arithmetic and since the time unit is not necessary,
TimeValue has been replaced with java.time.Duration both in the parser
and throughout the AST

Parser now performs comparison folding for literals.
Paranthesized expressions are now allowed.
In the process refactored the folding code to make
it more compact.