A prototype for an alternative to #116253

This allows using match on semantic_text fields, but without the need to reimplement the logic for getting the inference results in ES|QL.
This leverages the same model of query rewrite phase we already have in _search on the coordinator.

I added a ChickenQueryBuilder to show that semantic search actually works, but what we actually want is to continue to use MatchQueryBuilder when the match query starts supporting semantic_text (which is in progress).
It also shows the two types of query rewrites that happen under the hood for semantic text, but those would not be directly exposed in ES|QL.

The nice thing about this approach is that we can reuse it when we add a knn function and we want to do something similar to the query_vector_builder:

{
  "knn": {
    "field": "dense-vector-field",
    "k": 10,
    "num_candidates": 100,
    "query_vector_builder": {
      "text_embedding": { 
        "model_id": "my-text-embedding-model",
        "model_text": "The opposite of blue" 
      }
    }
  }
}

Here the argument of knn is not a vector, but a text query with a specified model_id to transform the query text into a vector. We could use the same approach of having a QueryBuilder that gets a rewrite phase on the coordinator to get the embeddings. Then at least for knn, we do not have a requirement to have the concept of async functions in ES|QL.

While this PR is cutting a lot of corners I want to get some high level feedback on a few questions:

• do we agree that having a query builder rewrite phase is a better approach than semantic search in ES|QL #116253?
• I have put the query rewrite phase after the plan is analyzed (and optimized) in EsqlSession - is the a better place for it?
• with this approach every FullTextFunction would store its own QueryBuilder that would get rewritten on the coordinator. I guess we want every FullTextFunction to control the function -> query builder translation, but storing the QueryBuilder in the FullTextFunction takes this idea a bit further than some might expect

If we agree with this high level approach, the plan would be to split this into multiple phases:

1. All FullTextFunction will own their translation to Lucene queries and FullTextFunction instances will store their query builder.
2. Introduce the query rewrite phase on the coordinator that would rewrite the initial QueryBuilders for FullTextFunctions and rewrite the FullTextFunction nodes with rewritten QueryBuilders.
3. Finally - when MatchQueryBuilder supports semantic text, enable the match function to receive semantic_text fields to perform semantic search.