### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

Initiating a multipart S3 upload to LocalStack returns an XML document with a root element CreateMultipartUploadOutput. This causes an error in the ex_aws_s3 library I'm using. We've used the combination of LocalStack + ex_aws_s3 successfully for a few years and the error started occurring a few days ago.

### Expected Behavior

The element should be called InitiateMultipartUploadResult.

### How are you starting LocalStack?

With a `docker run` command

### Steps To Reproduce

#### How are you starting localstack (e.g., `bin/localstack` command, arguments, or `docker-compose.yml`)

    docker run -p 4566:4566 localstack/localstack

#### Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands)

    aws --debug --endpoint-url=http://localhost:4566 s3api create-multipart-upload --bucket my-bucket --key 'multipart/01'


### Environment

```markdown
- OS: Ubuntu 20.04.5 LTS
- LocalStack: latest
```


### Anything else?

S3 docs specifying InitiateMultipartUploadResult:
https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateMultipartUpload.html

Reference in official AWS Java client:
https://github.com/aws/aws-sdk-java/blob/ef22b94750d4c155d74b09012b3be5d9d98bbd33/aws-java-sdk-s3/src/main/java/com/amazonaws/services/s3/model/transform/XmlResponsesSaxParser.java#L1865

Where our particular error gets raised in ex_aws_s3:
https://github.com/ex-aws/ex_aws_s3/blob/7e12f2b0578b2620c047d2e44c40a6de8773584a/lib/ex_aws/s3/parsers.ex#L78
"""
Response serializers for the different AWS service protocols.
The module contains classes that take a service's response dict, and
given an operation model, serialize the HTTP response according to the
specified output shape.
It can be seen as the counterpart to the ``parse`` module in ``botocore``
(which parses the result of these serializer). It has a lot of
similarities with the ``serialize`` module in ``botocore``, but
serves a different purpose (serializing responses instead of requests).
The different protocols have many similarities. The class hierarchy is
designed such that the serializers share as much logic as possible.
The class hierarchy looks as follows:
::
                                      ┌───────────────────┐
                                      │ResponseSerializer │
                                      └───────────────────┘
                                          ▲    ▲      ▲
                   ┌──────────────────────┘    │      └──────────────────┐
      ┌────────────┴────────────┐ ┌────────────┴─────────────┐ ┌─────────┴────────────┐
      │BaseXMLResponseSerializer│ │BaseRestResponseSerializer│ │JSONResponseSerializer│
      └─────────────────────────┘ └──────────────────────────┘ └──────────────────────┘
                         ▲    ▲             ▲             ▲              ▲
  ┌──────────────────────┴─┐ ┌┴─────────────┴──────────┐ ┌┴──────────────┴──────────┐
  │QueryResponseSerializer │ │RestXMLResponseSerializer│ │RestJSONResponseSerializer│
  └────────────────────────┘ └─────────────────────────┘ └──────────────────────────┘
              ▲
   ┌──────────┴──────────┐
   │EC2ResponseSerializer│
   └─────────────────────┘
::
The ``ResponseSerializer`` contains the logic that is used among all the
different protocols (``query``, ``json``, ``rest-json``, ``rest-xml``, and
``ec2``).
The protocols relate to each other in the following ways:
* The ``query`` and the ``rest-xml`` protocols both have XML bodies in their
  responses whic