Decide on input variables for `terraform-meltano-aws` and similar IAC modules

As a follow-on from the conversation in #2987 (internal), I thought it would be helpful to start discussing what configuration levels would be built into our Meltano IAC module for Terraform. To be sure that we have a specific-enough proposal without getting overwhelmed, I think we can describe this in AWS constructs _first_ and later translate these into the relevant constructs for GCP, Azure, etc.

## Functional data project configuration

These inputs drive core functionality of the Meltano project:

- `meltano_project_file` (str) - The path to a `meltano.yml` file to use in configuration of the environment. This would be [parsed by terraform](https://www.terraform.io/docs/language/functions/yamldecode.html) and may affect which resources Terraform creates, and how many. (Altering `meltano.yml` may require rerunning `terraform apply`.)
- `meltano_project_dir` (str) - The path to the Meltano project folder containing job definitions, dbt transforms, etc.
- `meltano_environment_name` (str) - The name of the environment to deploy, corresponding to a key in the `environments` entry in `meltano.yml`. This drives environment variable names and other configs as needed for the chosen environment. 
- `project_shortname` (str) - When AWS resources are created, they will be created with this text in the resource name.
- `aws_region` (required, str) - The region ID (e.g. `us-east-2`)

To keep the config DRY, most/all other configuration would ideally be migrated into _either_ the `environments` feature in `meltano.yml` _or_ the base plugin or utility config. Then `meltano.yml` (and possibly also `discovery.yml`) would be read as an input to the Terraform module's configuration.

## Optional, AWS infrastructure reuse and interop:

These inputs are all optional, and they allow the Terraform module to reuse existing AWS resources if desired:

- `use_existing_vpc_id` (optional, str) - The existing VPC ID to use. If null, a new VPC will be created.
- `use_existing_private_subnets` (optional, list(str)) - The existing private subnets to use. If null, a new VPC will be created.
- `use_existing_public_subnets` (optional, list(str)) - The existing private subnets to use. If null, a new VPC will be created.
- `use_existing_s3_logging_path` (optional, str) - The S3 path to use for logging purposes, when S3 log location is needed. If not provided, a new S3 bucket will be created.
- `use_existing_s3_artifacts_path` (optional, str) - The S3 path to use for storing temporary and long-term internal project artifacts, such as lambda function definitions, zip artifacts, and other internal project file storage. If not provided, a new S3 bucket will be created.

There may be more here but generally the config would follow the same pattern. In the first iterations, these may be all automatic - meaning we may not at first allow reusing existing resources. However, as the module matures, it should accept an increasing amount of interop and reuse with other environments, either for reasons of cost savings (RDS, K8 cluster, etc.) or corporate compliance policies (subnets, logging bucket, etc.). Most of these resources are free or have negligible cost, so probably would not need to prioritize reuse except for compliance reasons and for interop with existing application infrastructure.

Story points: 8.0