ESQL: Formalize common type conversions inside a query

[costin]

Description

A common pattern in certain queries is to declare values as strings even though the underlying consumer expects a different type - e.g. declare dates as strings; see #104547
Instead of addressing this locally, which can be problematic as the consumer has to perform both conversion and error reporting, this is better addressed in a centralized matter:

// instead of internal conversion
| AUTO_BUCKET(hire_date, 20,  "1985-01-01T00:00:00Z", "1986-01-01T00:00:00Z")

// use external, inlined conversion
AUTO_BUCKET(hire_date, 20, to_datetime("1985-01-01T00:00:00Z"), to_datetime("1986-01-01T00:00:00Z"))

For this to happen, the Analyzer would catch the type difference and add a synthetic conversion in place, which can then bubble up.
Note that we'd like the conversion to be applied early, in order to catch any potential failures as soon as possible.

P.S. This is a topic that occurred in SQL several times as well:
#49636
#77055

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[luigidellaquila]

It should be straight forward for binary operators (e.g. make left and right values uniform by converting one of the two).

For functions it could be more tricky, because the supported input types for each single function are defined in code and checked at resolution/validation time (resolveType() method); today we have no API that can tell the optimizer which types (and which type combinations, for multiple parameters) a function accepts.