feat: implement fast-follow placeholder website for firebase

[glasnt]

Implements #64

Using the image described in GoogleCloudPlatform/avocano#231, create a Cloud Run job that deploys a placeholder website. This will execute midway through the terraform processing, giving a "Your application is still deploying..." page.

Once the client deployment job runs, this placeholder is overwritten. The placeholder autofreshes through JavaScript every 5 seconds, so automatically updates when the avocano site is deployed.

This is faster than splitting the existing client/setup jobs into separate instances, as the client job depends on the cloud run API service, which depends on the database, which makes it low in the order of deployments. Deploying a placeholder without this dependency makes it higher in the order of operations, observed to be midway through the sql instance deployment, but definitely mid terraform deployment, which means it's ready before the window where Terraform is done but async metadata startup scripts haven't completed.

[grayside]

discussion: This cache purge shouldn't be necessary because we don't expect the firebase site URL to be exposed and checked before it's deploy is complete, unlike the final deploy which ends after tf apply completes. Would be great to learn if that's wrong (and if so, could we have an inline comment?)

[glasnt]

When I was testing this out, I had the URL open in a window, with the "Site not configured", and I found this helped clean that out with the placeholder. It shouldn't have to happen, I just found more success keeping it in.

[glasnt]

It's non-obvious, but tests are failing because the "plan after apply should have non-empty diff".

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.dynamic-python-webapp.google_compute_instance.placeholder_init[0] will be updated in-place
  ~ resource "google_compute_instance" "placeholder_init" {
      ~ desired_status            = "TERMINATED" -> "RUNNING"
        id                        = "projects/ci-dynamic-python-webapp-44c8/zones/us-central1-c/instances/placeholder-initialize-4ac0"
        name                      = "placeholder-initialize-4ac0"
        tags                      = []
        # (19 unchanged attributes hidden)

        # (5 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't
guarantee to take exactly these actions if you run "terraform apply" now.
    terraform.go:359: 
...
        	Error:      	Should not be: 2
        	Test:       	TestSimpleExample
        	Messages:   	plan after apply should have non-empty diff

This is because the placeholder GCE instance copied the desired_status from the "run migrations again if you run terraform" config from #46. The placeholder instance was long stopped, and should only be run once, so the desired_status can be removed.

It's presumed this instance stays running for a short time after terraform apply finishes, as it's running the jobs, so the state will still be running by the time this check is made. If this compute instance ends up synchronous, resulting in a plan diff by the time this check is run, this may need to be readdressed.

[glasnt]

@grayside merged the two PRs together, can I get your re-approval?

[glasnt]

Merging blocked pending GoogleCloudPlatform/cloud-foundation-toolkit#1575