feat!: Refactor count/lists into for_each/maps

[bmurphey]

Description

• Add an "accepter" resource for VPC attachments, to avoid the "auto accept shared attachments" feature when using Resource Access Manager (RAM)
• Add support for TGW Peering attachments
• Add Flow Logs for whole-TGW and/or individual TGW Peering/VPC attachments, publishing to S3 and/or CloudWatch Logs
• Convert tgw_routes from a list of maps to a map of maps, to avoid potential downtime associated with destroying routes when adding new ones
• Enable multiple TGW route tables to allow for more granular network segmentation
• Allow for adding multiple CIDR blocks to VPC route tables per-attachment, and rename the parameter from tgw_destination_cidrs to vpc_route_table_destination_cidrs to reflect its true purpose
• Add parameters to help transform implementation steps into a more cohesive order of operations
• Convert TGW route destination CIDR block to list, to allow multiple CIDR blocks per attachment
• Allow for disabling non-default route table propagation, to ensure VPC CIDR block can be left out of TGW route table when only certain subnets should be routable

Motivation and Context

This module was missing quite a few features that are necessary for true multi-account operation, as well as operational concerns like logging.

• Closes fix: Change count for for_each on ram_principal_association due resource recreation #95
• Resolves fix: Use IPv6 CIDR block destination on route when IPv6 support is enabled #102
• Resolves Significant refactor #109
• Resolves Execution fails when using vpc_attachments[].vpc_route_table_ids #111
• Closes feat: Allow specifying additional TGW routes in attached VPCs #132
• Closes feat: Add support for security group referencing to transit-gateway m… #133
• Resolves Support Security Group Referencing #135
• Resolves Default association and propagation are always enabled #136

Breaking Changes

This PR includes breaking changes due to changes in data structures. The changes to data structures (converting lists/sets to maps, mostly) were necessary to prevent downtime during applies due to deleting/re-creating routes.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects
• I have executed pre-commit run -a on my pull request

I am running my refactor in production currently, using one AWS account as the hub, and several other AWS accounts as the spokes.

[github-actions]

This PR has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this PR will be closed in 10 days

[bmurphey]

@bryantbiggs anything I can help with to move this along?

[dash-aug]

Could we have a separate PR for adding flow logs? They're quite useful, and it's a shame they're "stuck" in this PR.