Easier access to details from version field

[cbuescher]

This is a follow up to #59773 in which we added support for a new field type for software versions.
During discussing the requirements for the new type some asks were made to be able to access common parts of the version string like the major, minor or patch version, whether the version is a pre-release or a release or wether a given stored value is valid under e.g. the SemVer naming conventions. This information would be useful in searches or aggregations e.g. for filtering out only "released" versions or hierarchically aggregating e.g. major, minor or patch versions.

While working on #59773 the following solutions were discusse:

• extracting this information already when indexing the values and storing them in subfields of the main field.
  • Advantages: fast and easy access in filters and aggs via named subfield
  • Disadvantages: additional storage cost for numeric / boolean fields. This could partially be alleviated by making this behaviour an opt-in via a parameter on the field type
• offering simplified access to version details through specialices scripting functions that would be able to extract e.g. major/minor etc... at runtime from the original value via scrpts. This was e.g. discussed here

However, none of the above ideas could be utimately aggreed on yet so we decided to postpone adding this extra functionality in the first version of the field type to re-discuss the goals and options which this issue is about.

[elasticmachine]

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

[cbuescher]

Draft for the second option factored out here: #62953

[elasticsearchmachine]

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

[javanna]

This has been open for quite a while, and hasn't had a lot of interest. For now I'm going to close this as something we aren't planning on implementing. We can re-open it later if needed.