fix(core): apps that use token-aware-stringify are construct-instanti…

…ation-order-dependent (#31470)

### Issue # (if applicable)

Closes #31345.

### Reason for this change

Any stringified value containing an intrinsic will use a custom resource to resolve this value at deploy time.

Today, this custom resource's logical ID will take the form `'CDKJsonStringify<number>'`,
where <number> is a counter incremented for each stringified value. This results in resource replacement updates for the custom resource when the order of construct instantiation is changed, like changing this:
```
const app = new App();
new SomeStack(app, 'Stack1');
new SomeStack(app, 'Stack2');
```

to:

```
const app = new App();
new SomeStack(app, 'Stack2');
new SomeStack(app, 'Stack1');
```

This only happens if `SomeStack` stringifies a token, which some CDK constructs will do automatically. These resource replacements won't affect customer infrastructure, but customers using a common setup as in #31345 will see diffs on the same application in different environments, which violates the repeatability promise of CDK.

### Description of changes

Generate a unique identifier from the token's value instead of a counter. This makes this logical ID no longer instantiation-order dependent.

**This will cause diffs when upgrading**.

### Description of how you validated changes

Unit, integration, and manual tests.

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

packages/@aws-cdk-testing/framework-integ/test/core/test/integ.logical-id.ts

@@ -20,5 +20,3 @@ new sqs.Queue(stack, 'test01234', {
 new integ.IntegTest(app, 'LogicalIdTest', {
   testCases: [stack],
 });
-
-app.synth();