resource_missing_tags: rewrite to only consider keys

[bendrucker]

Rewrites the resource_missing_tags rule to explicitly deal with slices of keys instead of maps. In doing so, it acknowledges that keys may be unknown, which should fix #516 (in theory). When unknown keys are found we should return early and skip checking that resource. This PR also refactors this cty.Value to []string logic out as it was previously duplicated in two locations.

While a map would be more efficient and map[string]struct{} approximates a set in Go, the sizes are small enough that the clearer code of slices makes more sense. There was a bunch of wasted effort (and bugs) in dealing with tag values when ultimately we don't care about the tag values at all, just the keys. In cases where we're merging two lists of tag keys there's no need to de-duplicate as ultimately we are just looking at whether the slice contains our tag of interest.

It's not actually possible to test this currently as it's impossible to produce an unknown map value within what's allowed by the test runner, as far as I can tell.

This won't work:

resource "aws_s3_bucket" "b" {
  name = "b"
  tags = {
    (var.tag) = "t"
  }
}

Errors with:

Null value as key; Can't use a null value as a key.

[wata727]

AsString causes a panic under the following conditions:

• Marked as sensitive
• Not a string
• NULL

https://github.com/zclconf/go-cty/blob/v1.13.2/cty/value_ops.go#L1385-L1391

As for sensitive values, we might Unmark them here (probably very few cases where tag keys are really sensitive). In other cases, it's probably invalid in Terraform, and like unknown values, it's good to skip inspection of the tag.

[bendrucker]

Terraform should reject a map with a null key, but I've handled that now anyway. I ended up ignoring marked keys too. They can easily be unmarked and inspected but if the user declared them sensitive it seems reasonable to treat them as a black box (unknown).

[wata727]

Nice!