[ES|QL] Add optional parameters support to KQL function

[afoucret]

Summary

This PR implements support for optional parameters in the ES|QL KQL function, allowing users to specify all KqlQueryBuilder parameters (case_insensitive, default_field, time_zone, and boost) through named parameters.

Additionally, it significantly improves the KQL parser's handling of case-insensitive fieldless queries.

Closes #135823

Key Changes

1. ES|QL Function Enhancement

• Added optional parameters map: Support for case_insensitive, time_zone, default_field, and boost parameters
• Backward compatibility: Existing KQL function calls continue to work without changes
• KQL function is now scorable: Was the only fulltext function that was not yet scorable.

2. Case-Insensitive Fieldless Query Parser Improvements

• Enhanced case-insensitive handling: When case_insensitive=true and no specific field is provided, the parser now creates individual field-specific queries instead of relying on MultiMatchQuery. It allows non case sensitive matching on keyword fields when searching all the fields.

Syntax Examples

ES|QL Function with Parameters

| WHERE KQL("title: value", {"case_insensitive": true})
| WHERE KQL("timeout", {"default_field": "logs.*", "time_zone": "Europe/Paris"})
| WHERE KQL("error", {"case_insensitive": true, "boost": 2.0})

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[elasticsearchmachine]

Hi @afoucret, I've created a changelog YAML for you.

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel

[carlosdelest]

LGTM.

As a follow up, should we add options to the DSL KQL YAML tests?

[krzee]

thank you!