add terraform_comment_syntax rule

[bendrucker]

This PR adds a terraform_comment_syntax rule that enforces the canonical # comment style as described in the Terraform syntax guide:

https://www.terraform.io/docs/configuration/syntax.html#comments

This was requested by a colleague who noticed that @TakeScoop's Terraform configuration contains a mix of # and // comments but that Terraform clearly recommends #.

Since this is an aesthetic preference, the rule is disabled by default.

In order to accomplish this, I've added a Files method to the runner which returns all files in the current module. I'm interested in some other syntax-oriented rules that would depend on that method, e.g. enforcing canonical block padding:

resource "foo" "bar" {
  attribute = "value"

  block {
    
  }
}

resource "foo" "baz" {
  # ...
}

[wata727]

Looks good!

[wata727]

👍

[wata727]

According to Terraform documentation:

Automatic configuration formatting tools may automatically transform // comments into # comments, since the double-slash style is not idiomatic.

After reading this, I wondered if terraform fmt would convert the comments automatically, but it doesn't seem so...
If Terraform convert comments with terraform fmt, we probably don't need this rule.

[bendrucker]

Agreed, I think anything detectable by terraform fmt or terraform validate should be a non-goal for tflint.

I suspect that in the real world a lot of users (if not most) have a a mix of comment styles. Double slash is pretty much everywhere except for shells. If your editor has a syntax definition for Terraform/HCL, the keyboard shortcut for opening a comment should use # but without that definition it'll likely default to //.

Enforcing one comment style would be breaking for terraform fmt -check and currently fmt just modifies whitespace. So it seems like a big undertaking for visual consistency.

The language about auto-formatting in the docs is definitely interesting, and comes from here:

hashicorp/terraform@39579e8

Seems like Terraform 0.12 would have been the best time to introduce this, given that users were already significantly rewriting their configs. Very possible that was being considered at the time and it was cut from the release.