Resolve chicken-vs-egg scenario of initial Heroku deployment vs initial DANDI Infrastructure deployment

[Girder](https://github.com/girder/terraform-heroku-girder4) is the basis for the DANDI Archive API -- https://github.com/dandi/dandi-infrastructure/blob/master/terraform/api.tf#L5-L6.

A chicken vs. egg scenario occurs when using Girder for Heroku deployments of DANDI Archive, as DANDI Archive **must be deployed at least once, applying its relevant Procfile** to Heroku, [as noted here in the Girder docs](https://github.com/girder/terraform-heroku-girder4/blob/master/README.md#note-on-initial-creation-of-heroku-apps), prior to Heroku dyno configuration being recognized in corresponding `dandi-infrastructure` Terraform code.

_However_, when initially deploying the DANDI Archive, certain environment variables must be set -- [in the Django settings file here](https://github.com/dandi/dandi-archive/blob/master/dandiapi/settings.py#L88-L112) -- these values are set by the [Terraform values set here](https://github.com/dandi/dandi-infrastructure/blob/master/terraform/api.tf#L27-L50) -- thus, it is impossible to provide a clean, initial `terraform apply`, causing a chicken vs. egg scenario where DANDI Archive needs to be deployed before `dandi-infrastructure`, but can't because of missing env vars set via Girder.

This ticket captures this issue -- there _are_ be step-wise mechanisms to get around this (e.g. LINC Archive/infrastructure's prior trial-and-error), albeit potentially messy and confusing to a new user.

Cc @satra @kabilar @yarikoptic @waxlamp

Start with terraform/api.tf and dandiapi/settings.py, then read Girder's README section on initial Heroku app creation. Trace the dependency between the first DANDI Archive deployment, Procfile recognition, and required environment variables; done means the initial deployment path is resolved and documented without a chicken-and-egg failure.

Written by the indexing model from the issue text.