Preserve AWS VPC Peering routes if they do not change

[jakedgy]

Use a for_each of the cross-product of route_table_ids -> VPC CIDR blocks to generate stable names for the requestor and acceptor aws_route resources.

If the order of the route tables changes, it forces replacement of all route tables which can cause downtime during an apply.

⚠️ Important ⚠️

Switching from a count to for_each changes all of the aws_route resource names, which can cause downtime during an apply. Callers will need to move the state of any existing aws_route resources to the new names to avoid any downtime.

For example, to move the state for the following aws_route:

  # module.vpc_peering.aws_route.requestor[0] will be destroyed
  # (because resource does not use count)
  - resource "aws_route" "requestor" {
      - destination_cidr_block    = "10.1.0.0/16" -> null
      - id                        = "r-rtb-xxxxyy" -> null
      - origin                    = "CreateRoute" -> null
      - route_table_id            = "rtb-xxxx" -> null
      - state                     = "active" -> null
      - vpc_peering_connection_id = "pcx-zzzz" -> null
    }
...
  # module.vpc_peering.aws_route.requestor["rtb-xxxx:10.1.0.0/16"] will be created
  + resource "aws_route" "requestor" {
      + destination_cidr_block    = "10.1.0.0/16"
      + id                        = (known after apply)
      + instance_id               = (known after apply)
      + instance_owner_id         = (known after apply)
      + network_interface_id      = (known after apply)
      + origin                    = (known after apply)
      + route_table_id            = "rtb-xxxx"
      + state                     = (known after apply)
      + vpc_peering_connection_id = "pcx-zzzz"
    }

Run the following command before the plan and apply:

terraform state mv module.vpc_peering.aws_route.requestor[0] module.vpc_peering.aws_route.requestor["rtb-xxxx:10.1.0.0/16"]

And module.vpc_peering.aws_route.requestor["rtb-xxxx:10.1.0.0/16"] should be unchanged.

closes #33

[jakedgy]

I'm reopening this because I'm unable to get the CI bots the correct permissions to run on my primary organization fork (#40).