aws_ec2: L2 Vpc Construct incompatible with CloudFormation Parameters for CIDR - breaks Service Catalog deployments

### Describe the feature

Add support for CloudFormation Parameters and Token-based CIDR values in the L2 aws_cdk.aws_ec2.Vpc construct to enable dynamic CIDR allocation at deployment time.

Currently, the Vpc construct requires concrete CIDR strings at synthesis time, which prevents using CloudFormation Parameters, Fn::Cidr functions, or any Token-based values. This limitation makes it impossible to create flexible, parameter-driven infrastructure deployments through AWS Service Catalog or other scenarios where CIDR blocks need to be specified at deployment time rather than synthesis time.

The proposed feature would allow the Vpc construct to:
1. Accept CloudFormation Parameters as CIDR values
2. Support Fn::Cidr for runtime subnet calculation
3. Maintain compatibility with existing L2 constructs (NACLs, VPC Endpoints, etc.)
4. Preserve backward compatibility with hardcoded CIDR strings

This would enable true infrastructure-as-code flexibility for enterprise scenarios where network configurations must be dynamic and parameter-driven.

### Use Case

I'm always frustrated when I need to deploy the same CDK infrastructure across customers with different CIDR requirements, but I'm forced to either hardcode IP ranges or completely abandon L2 constructs.

Specific scenarios where this blocks development:

1. AWS Service Catalog Products: When creating Service Catalog products for multi-tenant deployments, customers need to specify their own CIDR blocks to avoid IP conflicts with existing infrastructure. Currently, this is impossible with L2 Vpc constructs, forcing us to hardcode ranges or drop to complex L1 implementations.

2. Customer-specific deployments: When deploying infrastructure for different customers, each has their own network requirements and IP allocation policies. The inability to parameterize CIDR blocks means we can't create a single, reusable template.

3. Integration with existing L2 constructs: When forced to use L1 CfnVPC as a workaround, we lose compatibility with all other L2 networking constructs (NACLs, VPC Endpoints, Security Groups, etc.) that expect aws_cdk.aws_ec2.Vpc instances. This forces a complete rewrite of networking infrastructure using only L1 constructs, losing type safety and developer experience.

5. Dynamic subnet calculation: We need to calculate subnet CIDRs at runtime based on the provided VPC CIDR, but Fn::Cidr functions are not supported by the L2 Vpc construct, making dynamic subnet allocation impossible.

### Proposed Solution

Add a calculateAtRuntime?: boolean property to VpcProps that enables CloudFormation runtime CIDR calculation using Fn::Cidr, allowing the L2 Vpc construct to work with CloudFormation Parameters and Token-based values.

Desired usage:

# Service Catalog with CloudFormation Parameters
```
vpc_cidr = aws_cdk.CfnParameter(self, "VpcCidr", type="String")

vpc = aws_cdk.aws_ec2.Vpc(
self, "MyVpc",
cidr=vpc_cidr.value_as_string,
calculate_at_runtime=True, # Enable runtime calculation
subnet_configuration=[
aws_cdk.aws_ec2.SubnetConfiguration(
name="public",
subnet_type=aws_cdk.aws_ec2.SubnetType.PUBLIC,
cidr_mask=24
)
]
)
```

When calculate_at_runtime=True is set, the Vpc construct would internally use CfnVPC and CfnSubnet resources with Fn::Cidr functions for subnet allocation, instead of requiring concrete CIDR strings at synthesis time.

Benefits:
- Enables Service Catalog use cases with parameterized CIDR blocks
- Maintains L2 construct ecosystem compatibility
- Provides explicit control over calculation strategy
- Preserves backward compatibility (defaults to False)

This would allow the same L2 Vpc construct to work seamlessly with both static CIDR values and CloudFormation Parameters, eliminating the need to drop down to L1 constructs for dynamic networking scenarios

### Other Information

_No response_

### Acknowledgements

- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### AWS CDK Library version (aws-cdk-lib)

2.210.0

### AWS CDK CLI version

2.1024.0

### Environment details (OS name and version, etc.)

Windows 11

Start at the TypeScript Vpc construct and its VpcProps and subnet_configuration entry points; review the proposed use of CfnVPC, CfnSubnet, and Fn::Cidr for token-based values. Done means parameterized CIDRs and runtime subnet calculation work while hardcoded CIDRs and compatibility with existing L2 networking constructs remain intact.

Written by the indexing model from the issue text.