custom-resource: better log customization design for custom resource logs

### Describe the feature

## Challenges

In AWS CDK, some constructs implicitly create custom resources with associated providers that generate CloudWatch log groups. Customers currently have no way to customize these log groups, either by:

1. Using their own existing log groups instead of the generated ones.
2. Specifying the log retention period for the generated log groups.

As a result, when customers deploy stacks containing these implicit custom resources, the generated log groups are left orphaned, requiring manual cleanup by the customer.

## Affected Issues

The issues related to this challenge are:
- https://github.com/aws/aws-cdk/issues/33025
- https://github.com/aws/aws-cdk/issues/33116

## Affected Modules

This challenge affects all CDK modules that implicitly create custom resources with lambda function providers.

### Use Case

deploy any L2 constructs that have custom resources implicitly created.

### Proposed Solution

## Expected Experience

To improve the customer experience, it would be desirable to allow customers more freedom in customizing the log groups associated with these implicit custom resources, such as:

1. Enabling customers to specify their own existing log groups for the custom resource providers to use, instead of generating new ones.
2. Allowing customers to set a default log retention period for the generated log groups, to avoid orphaned log groups.
3. Exploring other ideas that give customers more control over the log group configuration for these implicit custom resources.

### Other Information

_No response_

### Acknowledgements

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

### CDK version used

2.177.0

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

all

Start by reviewing the affected issues #33025 and #33116 and the CDK modules that implicitly create custom resources with Lambda providers. Determine how existing and generated CloudWatch log groups are handled across those modules. Done means an agreed design and implementation path for supplying existing log groups, setting default retention, and preventing orphaned logs.

Written by the indexing model from the issue text.