Extending Nested Processes chaining to allow alternative types

[fmigneault]

At the moment, Part 3 Nested Processes strongly assumes the process URL that is specified as input to another process corresponds to an OGC API - Processes reference. While this is a fine assumption by default, there isn't really any reason to enforce this. More specifically, creating a processing job allows the mention of a type property, which hints that other kinds of processes than OGC API - Processes could be used (e.g.: a remote WPS, an openEO process, etc.)

Part 4 explicitly extends this job type to allow WPS and openEO. This opens more opportunities for interoperability between those processing APIs, and creating more powerful workflows that process data where (and how) it can be pre-processed to limit data transfer.

Given that many of those APIs can have similar endpoints and/or I/O definitions, it would be useful to have a type property that can help the workflow/chaining processing engine resolve how to interact with them (provided the engine supports those APIs of course).

For example, the following would be possible:

process: "https://example.com/ogcapi/processes/some-oap-process"
inputs: 
  imagery-input:
    process: "https://example.com/openeo/processes/some-openeo-process"
    type: "openeo"
    inputs:
      stac-collection:
        collection: "https://example.com/collections/sentinel-2"
  climate-input: 
    process: "https://example.com/ows?service=WPS&request=DescribeProcess&identifier=some-wps-process"
    type: "wps"
    inputs:
      climate-index:
        type: application/netcdf
        href: "https://example.com/thredds/some-netcdf.nc"