feat: Support responses with multiple media types in content

[nkrishnaswami]

This PR modifies openapi-python-client to recognize multiple media types in OpenAPI response objects and to differentially parse HTTP responses based on their Content-Type header values. (Today, it generates code for a single content media type of the ones it encounters in the OpenAPI document.) This is useful eg for modeling services where a load balancer can send a 429 with plain text but the service behind it might send one with a schematized JSON response type.

Feedback is welcome, especially on the overall approach.

This PR adds unit tests and one end-to-end test, the latter of which includes sample generated code in the end_to_end_tests/multiple-media-types-golden-record/ subdirectory.

To maintain backward compatibility and minimize impact on existing callers, unexpected response content types raise the existing UnexpectedStatus error, rather than introducing a new error class

Uncovered diff lines:

1. openapi_python_client/parser/properties/protocol.py:71: This is one of two properties added that wrap the getter functions for the type string and instance type string to allow them to be used in Jinja templates.

    @property
    def instance_type_string(self):
        return self.get_instance_type_string()  # uncovered

2. openapi_python_client/parser/openapi.py:204: This is a "belt-and-suspenders" check to avoid accessing an optional field if it is null. However, responses.py will not actually populate any MediaType instances with a null prop.

         for media_type in response.content:
             if not media_type.prop:
                 continue  # uncovered
             endpoint.relative_imports |= media_type.prop.get_lazy_imports(prefix=models_relative_prefix)
             endpoint.relative_imports |= media_type.prop.get_imports(prefix=models_relative_prefix)
         endpoint.responses.append(response)