Support Iaas specific TF configs loading

[gberche-orange]

This is a refinement of the iaas-specifics-support to include terraform resource.

Currently, the current automation picks all TF config files.

cf-ops-automation/concourse/tasks/terraform_plan_cloudfoundry.yml

Lines 50 to 57 in 7a09101

	# copy spec in spec, preserving the nested modules if any
	find spec-resource/${SPEC_PATH}/ -mindepth 1 -maxdepth 1 -exec cp --verbose -r {} spec-applied/ \;
	# copy spec in secrets, preserving the nested modules if any
	if [ -d "secret-state-resource/${SPEC_PATH}" ]
	then
	find secret-state-resource/${SPEC_PATH}/ -mindepth 1 -maxdepth 1 -exec cp --verbose -r {} spec-applied/ \;
	fi

Sharing the same cf-ops-automation based templates across root deployments leveraging distinct TF config (e.g. openstack and cloudstack) is likely to dammage TF config readeability

The apparent TF syntax support is the conditional support in interpolation:

    A common use case for conditionals is to enable/disable a resource by conditionally setting the count:

    resource "aws_instance" "vpn" {
      count = "${var.something ? 1 : 0}"
    }

    In the example above, the "vpn" resource will only be included if "var.something" evaluates to true. Otherwise, the VPN resource will not be created at all.

Wrapping this logic into modules only enables to factor out the conditionals variable and does not alleviate the readability issue causes in every invoked resources having the conditional count interpolation as illustrated into hashicorp/terraform#12906 (comment)

It may make more sense to conditionally load different TF config files depending on a per root deployment flag (such as in ci-deployment-overview.yml ci-deployment.x-depl.terraform_config.iaas_spec-prefix)

This may for instance translate into naming convention on additional directories where to fetch iaas-specific spec files such as "specs-openstack" and "specs-cloudstack"

[o-orand]

Existing Iaas_type works for bosh deployment has been make through #60 and #102.