Support DynamoDB GSI creation merging with existing indexes

It is not possible to create more than one GSI at once due to an error "Cannot perform more than one GSI creation or deletion in a single update" and the CloudFormation team seems to consider this (absurdly so) as a "wont fix". Unfortunately, it's not on the short term roadmap for DynamoDB either so an alternative solution is necessary.

Proposed solution:
Support resolving drift of GSIs by updating those attributes in CloudFormation in a way that matches the existing state of the table.

This way, an engineer that experiences this bug with CloudFormation/DynamoDB can resolve it without creating incremental stack changes and deploying them sequentially. The flow would work like this:
1. Engineer sees error "Cannot perform more than one GSI creation or deletion in a single update"
2. Engineer manually creates those indexes in a way that matches the failed stack update.
3. Engineer attempts to deploy the stack again.
4. Instead of failing (because CloudFormation compares against the existing stack configuration), the stack update will succeed by skipping the UpdateTable indexes operation because it compares against the existing DynamoDB table configuration and determines there are no changes to indexes. The "change" would be relatively immediate because it is really just drift correction, not an update operation to dynamodb.

No repository files or tests are named in the issue; start by reading the proposed GSI drift-resolution flow and the DynamoDB update constraint. Done means a retry after manually creating matching GSIs succeeds by skipping the index update rather than issuing multiple GSI operations.

Written by the indexing model from the issue text.