Neptune: allow specification of read-replica instance props as part of DatabaseClusterProps

### Describe the feature

When creating a cluster with the `DatabaseCluster` construct, it is not possible to control the attributes of the instances created automatically by the cluster construct, you can only specify the count.

This issue proposes the ability to specify more than just the instance count and inherited size of the read replicas created by the `DatabaseCluster` construct.

### Use Case

There are a number of disadvantages to the reader instances being opaquely managed by the `DatabaseCluster` construct:
1. Reader size cannot be specified independently of Writer sizes.
1. An example of this being a problem is when the writer experiences frequent heavy load and causes readers to fail-over. The primary mitigations are to either reduce write speed (often undesirable) or to scale the readers to an instance larger than the writer. This is not easy with the current behaviour.
1. The implicit behaviour of `instances` mapping to the creation of `1` writer and `instances - 1` readers is unclear to new users
1. Removal policy cannot be specified for readers and writers separately. Often, you want to RETAIN the writer/cluster, but allow readers to be added/removed without them lingering. The only way to obtain this behaviour currently is to set `RemovalPolicy.DESTROY` on the cluster (dangerous)

### Existing Example

If we want to configure readers and writers separately, the current model must be adopted.

Notice that another side-effect of managing them separately is that the created cluster does not seem to be aware of the instances assigned to it when they are created separately. This makes workflows where retrieving instance identifiers tricky as they must be tracked manually.

```ts
const dbCluster = new DatabaseCluster(this, "GraphDatabase", {
...
instanceType: InstanceType.R6G_4XLARGE,
removalPolicy: RemovalPolicy.RETAIN,
instances: 1,
parameterGroup,
});

// Required to track this independently of the dbCluster as adding new instances
// below does not automatically update the clusters instance identifiers list
const instanceIdentifiers = dbCluster.instanceIdentifiers;

const readerCount = 4;
for (let i = 0; i < readerCount; i += 1) {
const instance = new DatabaseInstance(this, `ReadReplica-${i + 1}`, {
cluster: dbCluster,
instanceType: InstanceType.R6G_2XLARGE,
removalPolicy: RemovalPolicy.DESTROY,
parameterGroup,
});
instanceIdentifiers.push(instance.instanceIdentifier);
}
```

### Proposed Solution

This proposes that the `DatabaseClusterProps.instances` field should allow either a number (as it is now), or optionally an array of `DatabaseInstanceProps`, each one mapping to each additional read-replica.

Alternatively, a `readReplicaConfigurations: DatabaseInstanceProps[]` prop could be added, in which case.

### Example with proposed `readReplicaConfigurations` prop

```ts
// Define read-replica configurations
const readReplicas: DatabaseInstanceProps[] = []
const readerCount = 4;
for (let i = 0; i < readerCount; i += 1) {
this.readReplicas.push({
instanceType: InstanceType.R6G_2XLARGE,
removalPolicy: RemovalPolicy.DESTROY,
// Any instance props not supplied are inherited from the cluster
});
}

// Create cluster with read replica configs
const dbCluster = new DatabaseCluster(this, "GraphDatabase", {
...
instanceType: InstanceType.R6G_4XLARGE,
removalPolicy: RemovalPolicy.RETAIN,
readReplicaConfigurations: readReplicas,
// instances: 1 is implicit now because of readReplicaConfigurations being supplied
parameterGroup,
});

```

### Other Information

_No response_

### Acknowledgements

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

### CDK version used

cdk 2.63.0, aws-neptune-alpha 2.63.0-alpha.0

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

MacOS Ventura

Start with the DatabaseClusterProps and DatabaseInstanceProps APIs in the aws-neptune-alpha construct described by the issue, then compare the existing DatabaseCluster and separately managed DatabaseInstance usage. Done means callers can configure read-replica instance properties independently, including size and removal policy, while preserving cluster instance identifier tracking.

Written by the indexing model from the issue text.