Cloudfront hosting: invalid default cache behaviour for deployed web sites

### Before opening, please confirm:

- [X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
- [X] I have [searched for duplicate or closed issues](https://github.com/aws-amplify/amplify-cli/issues?q=is%3Aissue+).
- [X] I have read the guide for [submitting bug reports](https://github.com/aws-amplify/amplify-cli/blob/master/CONTRIBUTING.md#bug-reports).
- [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
- [X] I have removed any sensitive information from my code snippets and submission.

### How did you install the Amplify CLI?

npm

### If applicable, what version of Node.js are you using?

14

### Amplify CLI Version

7.6.5

### What operating system are you using?

Mac

### Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No change

### Amplify Categories

hosting

### Amplify Commands

add, configure

### Describe the bug

When using `Amazon CloudFront and S3` as a hosting, a lot of js and css files are fingerprinted (they have a unique names). Some other files like `index.html` are not. For these files, as their name will not change from one deploy to another but their content will, we need to consider the browser's cache behaviour in this case.

Currently there is no way to set a cache header for specific files when using `Amazon CloudFront and S3`. There is one way when we host via the Amplify Web console here: https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.html

What happens around browser cache behaviour when cache headers are not provided? Browsers will then use a heursitic based on the file last modified time. Some more information is available here: https://docs.aws.amazon.com/amplify/latest/userguide/custom-headers.html

It is safe to say that without the cache control header, the behaviour is not deterministic. Suppose a user came to your website a day ago with `index.html` having no cache-control headers set. When he came, the last modified date for this file was 1 month ago. Today you are publishing an update and the user comes back to the website. The browser will keep caching the old `index.html` file for the next 3 days, at least. The old `index.html` file has references to css and js that are outdated. That means your whole website will be outdated to this user for the next three days.

### Expected behavior

We would expect that when using `Amazon CloudFront and S3` as a hosting, the created architecture would have sensible defaults (or bug free behaviour) when it comes to caching.

Two things would enable this:
1. Having the AWS Amplify CLI considering the custom headers as well for `Amazon CloudFront and S3` hosting. We imagine this would mean that during `amplify publish` the CLI would look through the `amplify.yml` CustomHeaders section and push the file to S3 with the correct meta-data. Someone took a stab at it already by the look of it: https://github.com/aws-amplify/amplify-cli/issues/6393 , PR: https://github.com/aws-amplify/amplify-cli/pull/6879 while other users also ask for this behaviour here: https://github.com/aws-amplify/amplify-cli/issues/167
2. Having sensible `customHeaders` patterns provided by default in `amplify.yml` or in documentation.

Together, these two things would allow amplify users to add a `Amazon CloudFront and S3` hosting without having to deal with weird cache behaviours. Currently the only way avaiable we found to deal with these kind of issues is to build some custom scripts that hook into the deployment process, customizing the files' headers after deploy is done. Clearly, the framework could take ownership of this (like it does when deploying to Amplify Console).

### Reproduction steps

1. Add a Amazon CloudFront and S3 hosting solution.
2. See that adding CustomHeaders in `amplify.yml` is not used to set the metadata of the files on S3.

### GraphQL schema(s)

_No response_

### Log output

_No response_

### Additional information

_No response_