Extending Nested Processes chaining to allow alternative types

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"

Start with Part 3's Nested Processes requirement and the linked statusInfo.yaml type property, then compare how Part 4 extends it for WPS and openEO. Determine the specification changes needed for typed nested processes and define done as an agreed, interoperable rule for resolving and invoking supported alternatives.