all: need a decision on how to deal with project IDs in tests

[cflewis]

AWS tests don't require project IDs, nor most GCP ones, as they use the default project set in aws or gcloud. runtimevar actually does, because it to build URLs that use that project ID.

@zombiezen thinks the best thing to do is to force flags to be passed to all of them to avoid magic, although this might break vgo test ./... (not that I've been able to make it work TBH, I always cd to where I want to test from). I see the point here, but the practical downside is problematic.

The other option is for tests that do need them to shell out to gcloud (no programmatic way due to golang/oauth2#241).

[ijt]

Using a flag is problematic because all tests would have to know about clouds and projects. Environment variables don't have this problem.

One possibility is to have a $CLOUD_PROJECTS environment variable with a comma-separated list of cloud:project. It could be used like this:

CLOUD_PROJECTS=aws:project1,gcp:project2 vgo test ./...

[vangent]

We've decided to use Terraform for this. Basically:

1. User runs Terraform to provision any resources needed for the test, and output.tf saves their names for use as test inputs (e.g., bucket name).
2. User runs the test with --record, which makes a copy of output.tf for later replay and uses the inputs.
3. User runs Terraform to clean up.

I'll open separate issues with more specific tasks.