Add schema artifacts for future nested sourced_from feature

[ellisandrews-toast]

Context

ElasticGraph's existing sourced_from feature allows top-level fields on an indexed type to be populated from events of a different type. We're extending this to support nested sourced_from — where fields on embedded objects within an indexed document can also be populated from external events. This requires new runtime metadata to tell the indexing painless script how to navigate into the nested document structure and apply updates to the right element.

Summary

This PR introduces the data model and plumbing for the upcoming nested sourced_from feature. All new params flow through the system as empty values.

What this PR adds

• ListPathSegment / ObjectPathSegment — Data classes representing path segments for navigating to nested elements (list elements matched by key, or object fields)
• SourcedFromNestedParams — bundles per-event params (field_params + path_identifier_params) for nested update targets
• sourced_from_nested_paths_by_relationship field on IndexDefinition — static per-index config describing navigation paths
• sourced_from_nested_params field on UpdateTarget — per-event param resolution
• SourcedFromNestedPathSegment module — discriminates segment types via .key?("match_field") (no type field in YAML; painless-facing to_painless_param still includes type for script discrimination)

Why land this separately

Later PRs will add the painless script logic (which references these params) and the schema definition code (which populates them with real values). By landing the data model and plumbing first, those PRs can be reviewed in isolation without worrying about serialization format or param wiring.

[myronmarston]

LGTM apart from one minor suggestion.