Execute bbox conflicting definition with generic object

[Francis Charette-Migneault]

The following schema definitions:

ogcapi-processes/openapi/schemas/processes-core/inputValueNoObject.yaml

Lines 1 to 9 in 8c41db3

 oneOf: 
   - type: string 
   - type: number 
   - type: integer 
   - type: boolean 
   - type: array 
     items: {} 
   - $ref: "binaryInputValue.yaml" 
   - $ref: "bbox.yaml" 

ogcapi-processes/openapi/schemas/processes-core/inlineOrRefData.yaml

Lines 1 to 4 in 8c41db3

 oneOf: 
   - $ref: "inputValueNoObject.yaml" 
   - $ref: "qualifiedInputValue.yaml" 
   - $ref: "../common-core/link.yaml" 

ogcapi-processes/openapi/schemas/processes-core/qualifiedInputValue.yaml

Lines 1 to 8 in 8c41db3

 allOf: 
   - $ref: "format.yaml" 
   - type: object 
     required: 
       - value 
     properties: 
       value: 
         $ref: "inputValue.yaml" 

ogcapi-processes/openapi/schemas/processes-core/inputValue.yaml

Lines 1 to 3 in 8c41db3

 oneOf: 
   - $ref: "inputValueNoObject.yaml" 
   - type: object 

Make it such that the following input is valid under multiple oneOf cases of the schemas:

{
    "inputs": {
        "some_bbox": {
            "value": {
                "bbox": [1, 2, 3, 4]
            }
        }
    }
}

Either a not condition should be added for the generic type: object of inputValue to avoid matching the bbox fields, or replace the inputValue.oneOf by inputValue.anyOf. To avoid more ambiguity, additionalProperties: false for bbox should also be considered.

This is similar to the ambiguity that what addressed in #191

Relates to crim-ca/weaver#379, crim-ca/weaver#541, crim-ca/weaver#51