Potentially cached values in cdk.context.json can break deployments

Seems like CDK is caching values in cdk.context.json that are not always updated on cdk bootstrap or cdk deploy.

For example, just ran into a case where cdk.context.json contained cached local VPC/subnet details:

{
  "vpc-provider:account=000000000000:filter.isDefault=true:region=us-east-1:returnAsymmetricSubnets=true": {
    "vpcId": "vpc-69bd3613",
    "vpcCidrBlock": "172.31.0.0/16",
    "availabilityZones": [],
    "subnetGroups": [
      {
        "name": "Public",
        "type": "Public",
        "subnets": [
          {
            "subnetId": "subnet-47b445b3",
            "cidr": "172.31.0.0/20",
            "availabilityZone": "us-east-1a",
            "routeTableId": "rtb-b807fb5a"
          },
          {
            "subnetId": "subnet-99289971",
            "cidr": "172.31.16.0/20",
            "availabilityZone": "us-east-1b",
            "routeTableId": "rtb-b807fb5a"
          },
  ...

... and upon deployment of an AWS::RDS::DBSubnetGroup resource that was referencing one of the subnets, the deployment failed, as this subnet was no longer returned from awslocal ec2 describe-subnets (double-checked that the region was correct).

botocore.exceptions.ClientError: An error occurred (InvalidSubnetID.NotFound) when calling the CreateDBSubnetGroup operation: The subnet ID 'subnet-47b445b3' does not exist

We should consider deleting the cdk.context.json cache file (or updating its entries) on cdklocal bootstrap and/or cdklocal deploy, to ensure we're not using stale entries for deployment..

/cc @dominikschubert

Start by tracing how cdklocal bootstrap and cdklocal deploy handle cdk.context.json, then reproduce the stale-subnet case with awslocal ec2 describe-subnets. Check whether cached VPC and subnet entries are reused during deployment; done means deployments no longer reference subnet IDs that the configured environment does not return.