fix #1032 by comparing string representations of types

[chavacava]

Closes #1032 by comparing string representations of types (and not relying on actual type information)

Failure messages were extended to provide the name of the type that can be omitted.
Failure position information were fixed to point to the type that can be omitted.

This new implementation of the rule spots more failures than the current implementation and it seems to not generate false positives.
The attached files contain the result of linting the telegraf codebase (cf #1032) with the current implementation and with the implementation proposed by this PR.
pr-result.txt
head-result.txt

[denisvmedia]

Lgtm

[denisvmedia]

We should also update the docs to remove the note I put there before.

[zak-pawel]

I tested this PR in the scenario from this issue: #1032
Your PR detects over 20 findings more (compared to what is now on master after this PR #1046 was merged), all findings are as valid as possible, zero false-positives.
Thanks!

[zak-pawel]

This change causes the first of the two compared arguments to be indicated in the results.
I don't know if this is a deliberate change, but it seems that it would be more consistent to indicate the first repeating argument (as it has been so far).

The same comment applies to return arguments.

[chavacava]

It's a deliberated change; the intent is to be coherent with the message ("repeated ... type ... can be omitted") by pointing to the type that it can actually removed/omitted.

[chavacava]

I tested this PR in the scenario from this issue: #1032 Your PR detects over 20 findings more (compared to what is now on master after this PR #1046 was merged), all findings are as valid as possible, zero false-positives. Thanks!

@zak-pawel thanks for taking the time to test the PR.