Improve body deserialization when content-type matches multiple keys in the content map

[simonjbeaumont]

It's possible for a single operation to have a response that contains two or more keys in its content map with the same type and subtype, differing only by the additional parameters. For example, application/json and application/json;stream=watch, as used in the Kubernetes API:

% cat kubernetes.yaml  | yq '[.paths.*.*] | flatten | .[].responses.*.content | select(.) | keys' | sort | uniq -c
     48 - "*/*"
    301 - "application/json"
     70 - "application/json;stream=watch"
    301 - "application/vnd.kubernetes.protobuf"
     70 - "application/vnd.kubernetes.protobuf;stream=watch"
    301 - "application/yaml"
      1 - "text/plain"

When deserializing a response, we should match against the most specific type. However, we're probably at the mercy of the ordering of the deserialization logic in the generated code, which, in turn, is probably derived from the order in which the contents appear in the OpenAPI document.