### 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
self, context: RequestContext, bucket: BucketName, expected_bucket_owner: AccountId = None
    ) -> None:
        call_moto(context)
        self._clear_bucket_from_store(bucket)
        self._cors_handler.invalidate_cache()
    def get_bucket_location(
        self, context: RequestContext, bucket: BucketName, expected_bucket_owner: AccountId = None
    ) -> GetBucketLocationOutput:
        """
        When implementing the ASF provider, this operation is implemented because:
        - The spec defines a root element GetBucketLocationOutput containing a LocationConstraint member, where
          S3 actually just returns the LocationConstraint on the root level (only operation so far that we know of).
        - We circumvent the root level element here by patching the spec such that this operation returns a
          single "payload" (the XML body response), which causes the serializer to directly take the payload element.
        - The above "hack" causes the fix in the serializer to not be picked up here as we're passing the XML body as
          the payload, which is why we need to manually do this here by manipulating the string.
        Botocore implements this hack for parsing the response in `botocore.handlers.py#parse_get_bucket_location`
        """
        response = call_moto(context)
        location_constraint_xml = response["LocationConstraint"]
        xml_root_end = location_constraint_xml.find(">") + 1
        location_constraint_xml = (
            f"{location_constraint_xml[:xml_root_end]}\n{location_constraint_xml[xml_root_end:]}"
        )
        response["LocationConstraint"] = location_constraint_xml[:]
        return response
    @handler("ListObjects", expand=False)
    def list_objects(