[Proposal] Consolidate use of ecs.version field

We have different sources of ECS fields, and different places where `ecs.version` can be set. This proposal attempts to define some explicit rules about the expectations of the `ecs.version` field.

The different sources of ECS fields definitions are, at least:
* Fields imported from ecs using `export`, where the version used is determined in `_dev/build/build.yml`.
* Fields imported using `import_mappings`, with no explicit versioning, but can be combined with `export` and also uses the definition in `_dev/build/build.yml`.
* Fields included by Fleet with `ecs@mappings` component template, since 8.13.

The proposal would be focused on making the final documents to have the greater known ECS version affecting the package, with two main tasks:
* [ ] [elastic-package] If a version is set in `_dev/build/build.yml`, `elastic-package` system tests must check that `ecs.version` is set to this version or greater. Package developers may need to add pipeline processors to satisfy this check.
* https://github.com/elastic/elastic-package/issues/1066
* [ ] [Fleet UI] If Fleet includes the `ecs@mappings` component template, it must also add a processor that sets `ecs.version`. The value used must be the max version between the latest version of ECS supported by the the stack and the version found in the document, if any. Notice that the versions of ECS and the stack [are not fully aligned](https://github.com/elastic/package-spec/issues/737#issuecomment-2084444586).

cc @ishleenk17 @zmoog @elastic/ecosystem @kpollich