Kops YAML validation with STATE_STORE

A fun edge case that I ran into on Master.

1. create a YAML with s3://mystate/mycluster.com

Example:

```YAML
apiVersion: kops/v1alpha2
kind: Cluster
metadata:
creationTimestamp: 2017-04-29T01:57:10Z
name: us-east-1.aws.k8spro.com
spec:
api:
dns: {}
authorization:
alwaysAllow: {}
channel: alpha
cloudProvider: aws
configBase: s3://aws.k8spro.com/us-east-1.aws.k8spro.com
```

2. set your KOPS_STATE_STORE to s3://aws.k8spro.com/test/us-east-1.aws.k8spro.com
3. run `kops create -f mycluster.yaml` create the public ssh key and update the cluster

You will get the clusterspec in `s3://aws.k8spro.com/us-east-1.aws.k8spro.com/test/us-east-1.aws.k8spro.com` and everything else in `s3://aws.k8spro.com/us-east-1.aws.k8spro.com/us-east-1.aws.k8spro.com`. Everything should be in what the configBase defines. So the STATE_STORE is overriding the cluster create, but not checking that it is defined correctly in the YAML.

**Questions**
1. So what should be the functionality?
2. Which is the source of truth? KOPS_STATE_STORE or `configBase`?

**Actions**

We need to fail on the create when the `KOPS_STATE_STORE` differs from the `configBase`.

Reproduce the issue with the YAML shown, KOPS_STATE_STORE set to the alternate S3 path, and `kops create -f mycluster.yaml`. Trace how `configBase` and `KOPS_STATE_STORE` are handled during create; done means creation fails when they differ instead of writing cluster data to separate paths.

Written by the indexing model from the issue text.