Runtime fields error handling improvements

[javanna]

#92380 introduced configurable error handling for runtime fields through the on_script_error mappings parameter. There's a couple of follow-ups that are still left to address:

• unify behavior between scripted runtime fields and script-less runtime fields (loaded from _source): script-less runtime fields are lenient by default and non-configurable, hence whenever there is an error in loading the field value from _source, the value will be ignored (equivalent behaviour to on_script_error: continue for scripted runtime fields). Scripted runtime fields will by default throw errors instead, and require setting on_script_error to continue to change that. The on error behaviour should be configurable for script-less runtime fields, while it is not. There is an opportunity to share the error handling code between the two as was tried in Reuse scripted runtime fields error handling in script-less runtime fields #92550. Also, multi-valued fields treatment should be unified: script-less runtime fields ignore any value that causes an error but those that can be loaded are exposed to search, while scripted runtime fields stop at the first error and ignore all the following values (previously successfully loaded values are exposed).

• Align default behaviour between script-less and scripted runtime fields: script-less continue on error, while scripted cause a shard failure at search time.

• Add support for configuring on_script_error at the search request level, so that users can decide to ignore all errors with one setting provided at search time rather than having to modify all their field types in the mappings.

• Report back information about runtime field scripts that failed as part of the search operation, whose errors were ignored (due to on_script_error being set to continue)

[elasticsearchmachine]

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

[elasticsearchmachine]

Pinging @elastic/es-search-foundations (Team:Search Foundations)