These changes are a proposal for how to manage infrastructure as code.

The basic idea is as follows:

 1. `env/` directory contains configuraiton specific to an environment.
    An 'environment' is any logical grouping of infrastructure that is
    specific to one particular use case, or location, or account, etc.
    Environments inherit configuration hierarchically. A component
    'airflow' in a directory 'dev' in a directory 'sfo2' in a directory
    'docean' will allow that 'airflow' component to inherit the configuration
    of those parent directories, so configuration never needs to be duplicated
    across environments. It also allows for simple perusal of configuration
    to find configuration values specific to an environment, or more global
    configuration.

 2. A `terraform/` directory contains a `root` directory, where root modules
    are kept. These modules are passed `terraform.sh.tfvars` configuration
    files from an `env/`. The module is designed to absorb configuration and
    apply changes the same way in all accounts, with some logic embedded in
    the Terraform code to work around differences in different environments.
    In this way, the same root module can be used for multiple environments,
    keeping the code DRY.

 3. A `terraform/` directory also contains a `sub` directory, which are
    sub-modules. Think of these as "libraries" of Terraform code. These are
    not always necessary, but sometimes the extra layer of abstraction is
    convenient. A well-designed root module is often enough for small
    projects without the need for sub-modules.

 4. Purpose-built deployment scripts are used to pass the `env/` configuration
    to the components being deployed, which may live in other directories
    (for example the `terraform/` modules directories). In some cases,
    symlinking to an `env/` directory can prevent the need to write a custom
    deployment script.

This proposal is not yet complete. Still to be completed:

 - Finish taking some existing Terraform modules and adapting them with
   new variables, and filling in the `env/` directories with new `.tfvars`
   files to carry the variables.

 - A guide to developing with this model

 - A guide to deploying with this model

 - Docker, GitHub Actions, and other code/configuration to execute deployment
   scripts using this model

 - Probably more... I'm done for the night :-)

…ion)