Avoid mixed-type arrays

[hylkevds]

This is a generalisation of #14.
In JSON encodings of specifications that originated in the XML world we often see mixed-type arrays. The example from #14:

"resultQuality": [
    {
        "nameOfMeasure": "DQ_Status",
        "DQ_Result": {
            "code": "http://id.eaufrance.fr/nsa/446#3",
            "label": "Niveau 2",
            "comment": "Donnée contrôlée niveau 2 (données validées)"
        }
    },
    {
        "nameOfMeasure": "DQ_Qualification",
        "DQ_Result": {
            "code": "http://id.eaufrance.fr/nsa/414#1",
            "label": "Correcte",
            "comment": "Correcte"
        }
    }
]

We also see this in "related" or "links" sections of documents (ELFIE examples come to mind).
Arrays like this make filtering problematic. There is no way to say "give me the observations that have a DQ_Status with label Niveau 2". In FROST you can do some filtering on arrays, but only if the items in the array are always in the same order, and that's an extension to the API.

It's much better to not use an array, but used named elements. The above example would then be:

"resultQuality": {
    "DQ_Status": {
        "code": "http://id.eaufrance.fr/nsa/446#3",
        "label": "Niveau 2",
        "comment": "Donnée contrôlée niveau 2 (données validées)"
    },
    "DQ_Qualification": {
        "code": "http://id.eaufrance.fr/nsa/414#1",
        "label": "Correcte",
        "comment": "Correcte"
    }
}

This allows the filter resultQuality/DQ_Status/label eq 'Niveau 2'

We might want to keep an eye out for other OGC specs that use arrays like that, and pester the authors about it.