Make this code callable as a module from other Terraform configurations

[crerwin]

In the spirit of #12 this PR provides the necessary changes to allow the configurations for each of the three providers to be called as a module from external Terraform configuration. This will allow developers to spin up clusters using this repo within the same Terraform state as other pieces of their overall infrastructure. It also makes it easier to use this repo for quickly spinning up and tearing down test clusters (which is my use case).

1. In all three cloud provider configurations, modify the path value for the whoami.sh script to be relative to the module.
2. Modify the path value for the ip detect script in the AWS configuration to be relative. I had to use locals due to variables not supporting interpolation, but the outside behavior should not change, i.e. it will default to scripts/cloud/aws/ip-detect.aws.sh unless the user provides another path by setting the ip-detect variable.
3. Modify all outputs to remove spaces in the output identifier, since you cannot reference a module's output from a calling configuration if its identifier contains spaces. Outputs with spaces in the identifier is something that apparently is not supposed to be supported by Terraform, but the enforcing validation is not in place. See Unable to use output with space in identifier hashicorp/terraform#16843 .
4. Added 3 test fixtures inside test/fixtures/ to test the functionality provided by this PR. They are minimal Terraform configurations that call the configuration for a specific cloud provider and pass the minimum necessary variables to pass a validate and plan. The variable values were taken from desired_cluster_profile.tfvars.example within each provider configuration, so they match the existing smoke tests. Fixtures can be used to test calling the configuration as a module by running terraform [validate|plan] -var-file=test.tfvars within the fixture folder.
5. Added these fixtures as new tests in ci_smoke_test.sh to ensure future changes to the provider configurations don't break this functionality. One big thing it won't catch is new outputs with invalid names, but it's a start.

If you're happy with the changes and they're merged, it's a good idea to start thinking about this repo as a set of modules with a specific interface. I'd recommend starting to tag releases so folks calling the module can pin to a specific release to avoid breaking changes.