Issue title: Provider problems when using kops' Terraform output as a module
 Issue body: I'm using kops terraform output as a module in our terraform setup. 

The setup defines a provider using the `assume_role` feature to create all resources in a different account, i.e. the provider looks like this:

```hcl
provider "aws" {
  version = "~> 0.1"

  region     = "${var.region}"

  assume_role {
    role_arn     = "arn:aws:iam38d1:d2b4:3d06:83e8:96a5:8c2:893d:aba5${var.account_id}:role/terraform"
  }
}
```

However, since kops defines it's own provider in the generated terraform config like this:

```
provider "aws" {
     region = "eu-central-1"
}
```

the provider setting is overwritten and the main account is used.

I see that it makes sense to include the provider in the terraform config as it is required when using it as a standalone terraform config. However, I'm wondering if you guys have any suggestion how to handle this case when using the terraform config as a module. Or maybe we could add a flag which indicates that we will use the terraform output as a module and thus omits the provider setting?
 Comments: 
 Comment 0: For anyone reading this issue: #4336 solves my problem and will hopefully get merged soon
 Comment 1: My PR is merged so running from **master** and any releases beyond today the following should work for you -

In your kops.yaml file, you can add the following block to the cluster spec :
```yaml
  target:
    terraform:
      providerExtraConfig:
        alias: ignoreprovider
```
I wish there was a way to sensibly include HCL in the yaml (so you could include the assume_role stuff), but that would require parsing the yaml differently and that's a step beyond what I want to achieve.  At least this should work for you as is.
 Comment 2: @iMartyn Thanks so much for your efforts!
 Comment 3: @iMartyn can we close this issue now?
 Comment 4: @chrislovecnm I think so, my instinct is to close issues when a release is done that includes the fix but not sure how this project deals with issue fixes.
 Comment 5: Issues go stale after 90d of inactivity.
Mark the issue as fresh with `/remove-lifecycle stale`.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with `/close`.

Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta).
/lifecycle stale
 Comment 6: @jhedev have you tested the latest release? 
 Comment 7: Stale issues rot after 30d of inactivity.
Mark the issue as fresh with `/remove-lifecycle rotten`.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with `/close`.

Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta).
/lifecycle rotten
/remove-lifecycle stale
 Comment 8: Rotten issues close after 30d of inactivity.
Reopen the issue with `/reopen`.
Mark the issue as fresh with `/remove-lifecycle rotten`.

Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta).
/close
{'source': 'GithubIssues', 'repo_name_with_owner': 'kubernetes/kops', 'issue_id': 287388161, 'repo_stars': 14763.0}