Make `setup-terraform` action more generalizable

[jeancochrane]

The setup-terraform action is currently tightly coupled to the build-and-run-batch-job workflow due to the interface we use to pass in config-specific variables. Currently, they are passed in as named input parameters, one for each variable:

actions/setup-terraform/action.yaml

Lines 12 to 46 in 2f9dd27

	batch-container-image-name:
	description: The name of the container image to use for the Batch job.
	required: true
	batch-job-definition-vcpu:
	description: >
	Count of vCPUs to provision for the container. Per AWS requirements,
	this parameter must be formatted as a float in increments of 0.25 when
	the backend is "fargate" (e.g. 1.0 for 1 vCPU), but it must be
	formatted as an integer when the backend is "ec2" (e.g. 1 for 1 vCPU).
	The minimum is 1 vCPU.
	required: true
	batch-job-definition-gpu:
	description: >
	Count of GPUs to provision for the container. Per AWS requirements,
	must be formatted as an integer. This parameter is only available when
	the backend is "ec2", otherwise Terraform will raise an error. An
	empty string indicates a null value, and is also the default.
	required: false
	type: string
	default: ""
	batch-job-definition-memory:
	description: Count of megabytes of RAM to provision for the container.
	required: true
	batch-compute-environment-backend:
	description: >
	The type of AWS Batch compute environment to provision. Must
	be one of "fargate" or "ec2". Fargate allows for provisioning
	fractional amounts of vCPU and tends to start up jobs faster, but EC2
	allows GPU instances to be configured using the `gpu` parameter.
	required: false
	type: choice
	options:
	- fargate
	- ec2
	default: fargate

This isn't a great design, because the batch-* variables are specific to build-and-run-batch-job, and if we wanted to use setup-terraform to provision resources for a different workflow (e.g. in model-sales-val) we would both A) be required to pass variables that are not used by the workflow's Terraform config and B) not have a way of passing different variables that are used by the workflow's config.

I think a better interface would be one input variable named something like terraform-vars that accepts a newline-delimited string of variables to set in the Terraform config. Then callers could pass in arbitrary key-value pairs to set as variables. See #6 for an example of a PR that implements a similar interface.