CloudFrontToS3: OriginAccessControl already exists

When using the `CloudFrontToS3` construct, there's an undocumented requirement around the `id` constructor parameter: The inner workings of this construct will only consider 9 characters of that ID passed in. Take an identifier like this `dev-svc-uploads-assets-cdn` which is completely reasonable. That gets transformed into `dev-s-cdn`. When you're deploying more than one CDN, that ends up in an `AlreadyExists` error. This is due to the inner workings in the `core`:

- `createCloudFrontDistributionForS3` is called from https://github.com/awslabs/aws-solutions-constructs/blob/c297b118628b63607ba9f9beaaf2234af586deac/source/patterns/%40aws-solutions-constructs/aws-cloudfront-s3/lib/index.ts#L180
- a new `CfnOriginAccessControl` construct is added, and the code tries to get fancy by creating it's own internal unique ID for the OAC here with `generatePhysicalOacName` here https://github.com/awslabs/aws-solutions-constructs/blob/c297b118628b63607ba9f9beaaf2234af586deac/source/patterns/%40aws-solutions-constructs/core/lib/cloudfront-distribution-helper.ts#L149C15-L149C38
- that redirects to `generatePhysicalName` here https://github.com/awslabs/aws-solutions-constructs/blob/main/source/patterns/%40aws-solutions-constructs/core/lib/utils.ts#L181 which slices and dices the original `id` passed in

The crux of this is that the function that tries to generate a unique ID doesn't follow CDK core's own algorithms, which it really should as that's one that doesn't run into conflicts.

Alternatively, we'd have properties we could provide that would override the ID generation.

At the moment, we have to use a patched dependency to get around this if we want to pass proper IDs that match our environment standards (in our case `{env}-{project}-{thing name}-{thing type}`

At the least, the user should know that their IDs are being squashed for resource IDs under the hood. Imagine trying to find this resource by name/id in the console and wondering where the heck it is because the ID you passed was turned into something unrecognizable.

### Reproduction Steps

```ts
const result = new CloudFrontToS3(scope, 'dev-svc-uploads-assets-cdn', { ... });
const result = new CloudFrontToS3(scope, 'dev-svc-uploads-media-cdn', { ... });
```

### Error Log

```
dev-svc-uploads-stack failed: Error: The stack named dev-svc-uploads-stack failed to deploy: UPDATE_ROLLBACK_COMPLETE: Resource handler returned message: "Resource of type 'AWS::CloudFront::OriginAccessControl' with identifier 'aws-cloudfront-s3-dev-s-cdn-466204b0-4968-11ef-acca-0affef817d45' already exists." (RequestToken: ecff76f4-c8bb-4910-11ed-fd67a61d9d6c, HandlerErrorCode: AlreadyExists)
```

### Environment

- **CDK CLI Version :2.1005.0
- **CDK Framework Version: 2.185.0
- **AWS Solutions Constructs Version : 2.79.1
- **OS : Mac
- **Language :TS

### Other

---

This is :bug: Bug Report

Start in source/patterns/@aws-solutions-constructs/aws-cloudfront-s3/lib/index.ts at createCloudFrontDistributionForS3, then follow generatePhysicalOacName in source/patterns/@aws-solutions-constructs/core/lib/cloudfront-distribution-helper.ts and generatePhysicalName in core/lib/utils.ts. Reproduce the issue with the two CloudFrontToS3 IDs from the report and verify that deployment no longer produces an OriginAccessControl AlreadyExists error and that the resulting resource identity is understandable.

Written by the indexing model from the issue text.