Add runtime field section to Field Capabilities API

[cbuescher]

Currently runtime fields from search requests don't appear in the output of the
field capabilities API, but some consumer of runtime fields would like to see
runtime section just like they are defined in search requests reflected and
merged into the field capabilities output.
This change adds parsing of a "runtime_mappings" section equivallent to the one
on search requests to the _field_caps endpoint, passes this section down to
the shard level where any runtime fields defined here overwrite the mapping of
the targetet indices.

Closes #68117

[elasticmachine]

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

[cbuescher]

One caveat of this PR: I found that we do not propagate back exceptions thrown in the shard operation in TransportFieldCapabilitiesIndexAction to the calling nodes in a good way currently. If there are errors in the runtime_mappins section, e.g.

{
  "runtime_mappings": {
    "day_of_week": {
      "type": "some_bad_type",
      "script": {
        "source": "emit(doc['@timestamp'].value.dayOfWeekEnum.getDisplayName(TextStyle.FULL, Locale.ROOT))"
      }
    }
  }
}

The resulting MapperParsingException in that is thrown when parsing the runtime fields upon creating the SearchExecutionContext on the shard is dropped somewhere. Fixing this is a bit more involved so I would prefer doing this in a follow up.

[jimczi]

LGTM

[javanna]

The change looks good to me, error handling looks like wasn't part of the initial design of field_caps and it now becomes more important as scripts may not compile etc. Although field_caps should not be used to validate scripts (and possibly we should not even need to compile them for field_caps), returning an empty response whenever there is an error does not seem like a good idea.

I'd say merge this one and let's discuss and work on the error handling as a follow-up?

[javanna]

would it make sense to add a test for the toXContent output of the request if we don't test it yet?

[cbuescher]

sure, will do