Logs retention policy is not applied to jars bucket autodelete custom resource

### Description / Background

When you set `sleeper.retain.logs.after.destroy` to true, there's a log group that is not deleted. This is the log group for the lambda that does the CDK built-in autodelete for objects in the jars bucket.

### Steps to reproduce

1. Deploy the Sleeper artefacts CDK stack
2. Delete the stack
3. See the log group is not deleted

### Expected behaviour

There should be a way to configure the artefacts CDK stack to not retain the log group.

When the artefacts stack is deployed as part of deploying an instance, e.g. with the scripts, this should be inherited from the instance property.

### Technical Notes / Implementation Details

The artefacts CDK stack is in a separate CDK app from the Sleeper instance. It doesn't currently read the instance properties at all.

We're using the built-in CDK behaviour to autodelete the jars in the jars bucket during teardown, but everywhere else in Sleeper's CDK code we use our own custom resource to do similar autodeletion. If we apply that custom resource we'll be able to control the log group.

Start with the artefacts CDK stack and the instance deployment scripts, then compare the built-in jars-bucket autodelete with Sleeper's existing custom-resource autodeletion. Trace how the instance property could reach the separate artefacts CDK app. Done means the retention setting is configurable and inherited during instance deployment, with the Lambda log group deleted when retention is disabled.

Written by the indexing model from the issue text.