redundant-build-tag: detect duplicated build constraint

[alexandear]

Is your feature request related to a problem? Please describe.

Extend the rule redundant-build-tag with functionality to find a duplicated build tag //go:build windows when a filename's suffix is _windows.go or *_windows_test.go.

Of course, instead of windows can be any GOOS or GOARCH. See https://pkg.go.dev/cmd/go#hdr-Build_constraints for more info.

Additional context

See this PR for an example go-delve/delve#3556

Request comes from the #1135 (comment)

[ccoVeille]

I had no idea about the implicit build tag from filenames.

TIL, thanks.

But, I'm unsure if it should be enforced in an existing rule.

So maybe config for the rule.

[denisvmedia]

I analyzed it a little bit. In fact we should check the following:

• if the explicit build constraints are not mutually exclusive with the implicit (file name) build constraints (e.g. if the file is named example_linux.go but has an explicit build tag //go:build windows) - in this case the file will not be included in any build.
• we should check if the explicit build constraints are fully covered by the implicit ones. E.g. file named example_linux.go and an explicit build tag //go:build linux && arm64 - in this case the explicit build tag is narrower and the file name constraint is excessive.
• we should check if the implicit build constraints are fully covered by the explicit ones. E.g. file named example_linux_arm64.go and an explicit build tag //go:build linux - in this case the implicit build tag is narrower and the explicit constraint is excessive.
• we should check if they are equal (none is narrower) - in this case the user should decide what to keep.
• we should check if they are equal in terms of OS/ARCH but the explicit build constraints have more build tags - in this case we should force the user to rename the file.

I might have missed more cases, but this illustrates the complexity of the task.