Add support for path-style endpoint in S3

### Please agree to the following

- [X] I have searched [existing issues](https://github.com/cryptomator/ios/issues?q=) for duplicates
- [X] I agree to follow this project's [Code of Conduct](https://github.com/cryptomator/ios/blob/develop/.github/CODE_OF_CONDUCT.md)

### Summary

Add support for path-style endpoint in S3 (instead of subdomain).

### Motivation

The current S3 implementation enforces the endpoint, where the bucket name is used as a subdomain, e.g., `https://.s3./`. A user reported that he'd like to use the path-style endpoint, e.g., `https://s3./`.

I'm not sure why this would become _necessary_ but it's still a limitation. The user faced an issue because the TLS certificate for `s3.` can't be used for `.s3.`, which is automatically enforced by Cryptomator.

### Considered Alternatives

This hasn't been confirmed yet but a workaround could be to issue a wildcard TLS certificate for `*.s3.`.

### Anything else?

There doesn't seem to be a quick fix at the moment: https://github.com/aws-amplify/aws-sdk-ios/issues/683

We're using this SDK for our S3 implementation and the `s3ForcePathStyle` configuration is not supported. They've mentioned that it has been addressed in a their Swift SDK but we're unable to use it at the moment since it's still marked as "developer preview" and discouraged to be used for production apps.

There seems to be a workaround though but it would require some time for us to try it out and implement.

Locate the S3 implementation and the AWS SDK endpoint configuration, then read how bucket names are currently incorporated into endpoint URLs. Determine how the existing workaround relates to the SDK limitation; done means the integration supports both subdomain-style and path-style S3 endpoints without breaking the current behavior.

Written by the indexing model from the issue text.