Consolidate release information into single metadata file that's consumed by builds and test

[alpar-t]

We should create a single metadata file such as for each version:

features:
    - rolling-upgrade 
    - fips
versions:
    7.0.0:     
         released: false
         latest-qualifier: alpha1
         supports: [ 'rolling-upgrade', 'fips' ]
         minimumJavaVersion: 8
         maxJavaVersion: 11    
testing:
    rolling-upgrade:
         from: '5.6.0'  
         project: ':qa:rolling-upgrade'
         task: ''

The actual fields in the final metadata will vary, we will only model what is needed, the above snippet is just a sample of how this could end up. The key takeaway is that :

• the information is factual, fine grained and complete. All information required for deciding on tests should be present here. It's expected that the implementation that reads this meta data will have methods like bwcVersions(feature) , javaVersion(feature, version) etc so the tests don't have to make that decision locally.
• provides an (also) human readable summary of which features are supported where and how we test them
• allows for some level of automatic validation

Steps:

• consensus on the approach and format
• start consuming these from tests and extending the metadata as we go
• write a task to validate that all tasks were generated and the dependency chain is correct for bwcTests the task would check the task graph and error out if bwcTests is on it but not all testing tasks are (assume consistent task naming).
• write a task to generate a .dot graph to visualize the testing that is done

References:

• Make the build version qualifier aware #32128
• Use JDK 10 for 6.4 BWC builds #32866

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

Discussed with @rjernst, turns out we had a more descriptive approach before and did not like the maintenance of it. Iterating on the current approach instead see #34050 for more details.