(apigateway): support deployment salting for imported RestApi

### Describe the feature

This is a continuation of the discussion in the (already closed) ticket: https://github.com/aws/aws-cdk/issues/12417

Having an API Gateway and its routes spread out across CDK/CloudFormation stacks is a good idea for a variety of reasons:
* Avoiding the 500 resources limit of CloudFormation
* Allowing different teams to maintain different parts of the API (Microservices pattern)

### Use Case

A moderately sized API Gateway with a few dozens of Resources and Methods inside, quickly exhausts the 500 resources limit of CloudFormation.

This is mostly because of the fact that every Resource and Method is composed of multiple sub-resources like, the Lambda, some IAM roles, CloudWatch LogGroup, Retention Policies to that LogGroup, etc, etc. So reaching the 500 count is very easy.

### Proposed Solution

The main reason why the previous ticket was closed was because the `new Deployment()` resource has no way of knowing when and if it should be redeployed, considering that routes (Resources and Methods) were possibly added by a different stack.

The reason why the `new Deployment()` is conditionally recreated properly when everything is in the same stack, is because the Resources and Methods can be attached as "dependencies" to the Deployment construct, so it is invalidated as soon as a Resource or Method is added or removed.

My proposal here is simple - develop a Custom Resource (Lambda) that internally queries the state of the API Gateway (collect all current Resources and Methods) and hashes them to a stable string. That string can then be used as a singular dependency to the `new Deployment()` construct, causing it to be recreated conditionally, only when the hash changes.

Here's a typical structure based on current recommendations:

Stack A:
* API GW
* Routes A
* Routes B
* Routes N
* Deployment
* Stage

What people want (me included):

Stack A:
* API GW

Stack B:
* Routes A
* Routes B
* Routes N

Stack C:
* Deployment
* Stage

The solution I'm proposing would change Stack C, to something like this (pseudo code):
```
const hasher = new ApiGatewayDeploymentSalter(this, 'Salter', {apiId: '123456'});
const deployment = new Deployment(this, 'Deployment')
const stage = new Stage(this, 'prod', {deployment});

// The `hasher` is a Lambda backed custom resource that hashes the current state of the API Gateway, based on the resources and method "tree"
deployment.addToLogicalID(hasher.ref);
```

### Other Information

_No response_

### Acknowledgements

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

### CDK version used

2.90.0

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

MacOS

Start at the API Gateway Deployment construct and its existing dependency and logical-ID behavior, then review how imported RestApi resources and methods are represented across stacks. Done means deployment salting detects changes to the current resource and method tree and recreates the deployment only when that state changes, using the proposed Lambda-backed custom resource.

Written by the indexing model from the issue text.