Schema for benchmark scenario definitions

[soxofaan]

Under #4/#13 I did initial setup of running benchmark scenarios, based on an initial use case definition.

Some things to discuss/(re)consider/finetune:

1. current structure of the JSON files is a top-level array with scenario objects ([ {"id": "...", ...}, {"id": ...} ]). This makes it impossible to add top-level properties in the future. Things we might want to add at top-level: references to owner/author, default values for parameters, run schedule constraints, credit constraints, .... Instead, change toplevel to an object, e.g.

   {
     "type": "benchmark-scenarios",
     "scenarios": [
       {"id": ...},
       {"id": ...},
     ]
   }

2. scenarios currently have "type": "openeo", but that is quite generic if you compare it how the "type" field is used in GeoJSON, STAC, OGC, ... I guess "type": "openeo" intends to say that this is a openeo based benchmark. I would make type a bit more verbose, e.g. "openeo-benchmark" or "openeo-process". Or use a different field name, e.g. "processing_mode": "openeo"
3. related to previous: is it intended to also have non-openeo benchmarks here?
4. Should benchmarks always run batch jobs, or should there be an option for sync processing too?
5. current examples don't have a save_result node, e.g. to set output format. We probably should set this explicitly to avoid depending on implicit behavior