feat: Add option to create SingleTableDatastore from existing DynamoDB table

[DerDackel]

• Please check if the PR fulfills these requirements

• The commit message describes your change
• Tests for the changes have been added if possible (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Extracted a basic interface for ISingleTableDatastore, that is implemented by SingleTableDatastore, so the udnerlying datastore can be created in other ways.

• What is the current behavior? (You can also link to an open issue here)

SingleTableDatastore will create its own aws_dynamodb.Table instance and expose only a limited amount of the settings. There is no way around this without either reaching into the CDK's escape hatch, or foregoing cdk-serverless' Single Table Datastore setup entirely.

• What is the new behavior (if this is a feature change)?

This change introduces a static method SingleTableDatastore.fromTable that takes an existing aws_dynamodb.Table instance and creates an implementation of ISingleTableDatastore that can be injected into cdk-serverless API constructs, allowing advanced users to configure a DynamoDB table on their own and use it within cdk-serverless.

• Does this PR introduce a breaking change? (What changes might users need to make in their setup due to this PR?)

SingleTableDatastore now implements the interface ISingleTableDatastore and the base API construct now expects that interface instead of the concrete implementation. Right now I do not see this breaking existing uses.

• Other information:

• I considered generalizing the type of aws_dynamodb.Table to its interface to allow the use of imported tables, but felt this was out of scope, as this might break common use cases where users access the table instance inside SingleTableDatastore after creation.

• Alternatively, overhauling the SingleTableDatastoreProps to expose most or all of the underlying aws_dynamodb.TableProps would be an option, but could create more friction with the existing API.

• The project only unit-tests projen components, not CDK constructs. Is this desired? This change is simple, but so would testing proper stack creation be.

[hoegertn]

Sounds like a great plan. That might also be helpful when creating a TableV2 option.