Improve validation of lambda concurrency settings

### User Story

As a user deploying Sleeper, I want to know straight away when I set a configuration that is not deployable, so that I don't have to wait for it to deploy and roll back before I can fix my problem.

### Description / Background

If you set `sleeper.statestore.committer.concurrency.reserved` to a value lower than `sleeper.default.lambda.concurrency.max` or `sleeper.statestore.committer.concurrency.max`, the CDK deployment will fail because it refuses to set the maximum concurrency greater than the reserved concurrency. It waits until it tries to deploy the lambda before failing, then rolls back the whole deployment.

We'd like to review the setup of our lambda concurrency configuration properties, and ensure that they're validated correctly and any relationships between them are clear in the documentation.

### Technical Notes / Implementation Details

Here's an AWS article that explains how maximum concurrency for a lambda works (this is set on an SQS event source for a lambda):

https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/

Here's the AWS documentation explaining reserved concurrency:

https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html

This can be tested in InstancePropertiesTest.

This is also related to:
- https://github.com/gchq/sleeper/issues/6934

See that issue for a discussion of how to handle validation of relationships between multiple properties.