aws-cloudfront-origins: support for Secret in OriginOptions.customHeaders

### Describe the feature

It should be possible to use an `aws-secretsmanager/Secret` (or `aws-cdk-lib/SecretValue`) with `aws-cloudfront-origins/OriginOptions.customHeaders` attribute without the need to unwrap the secret, insecurely exposing it in the template.

### Use Case

Providing a CDK generated secret to use between CloudFront distribution and Application Load Balancer, as recommended here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html

### Proposed Solution

Add support for `aws-secretsmanager/Secret` like in `aws-ecs/ContainerDefinitionOptions.secrets` ( `[key: string]: ecs.Secret` ) (or using similar approach) in `aws_cloudfront_origins/OriginOptions.customHeaders`.

### Other Information

Currently the `aws_cloudfront_origins/OriginOptions.customHeaders` attribute only supports a `Record`, so, providing a `aws-cdk-lib/SecretValue`'s value for a custom header forces one to use `SecretValue.unsafeUnwrap()`.

Ideally, secrets should not be exposed in the CF template, but rather be dynamically looked up like with the ECS container secret value injection mechanism.

### Acknowledgements

- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### CDK version used

2.29.1

### Environment details (OS name and version, etc.)

macOS Monterey and latest AWS CodeBuild AMIs

Start with aws-cloudfront-origins/OriginOptions.customHeaders and compare the requested behavior with aws-ecs/ContainerDefinitionOptions.secrets. Trace how CloudFront origin custom headers are represented in the generated template, then verify that a Secret or SecretValue can be referenced without unsafe unwrapping; done means the secret is not exposed as a plaintext template value.

Written by the indexing model from the issue text.