SONARKT-542 Fix CPD with string templates

[antonioaversa]

SONARKT-542

See here for a complete analysis of the issue.

The adopted solution is to treat the entire string template as a single LITERAL token. In the previous solutions, each KtStringTemplateEntry emitted a LITERAL token.

Downsides

This may not be perfect, as we may not detect duplication patterns in expressions within interpolations of a string template.
For example, the following string:

var x5 = """ 
    a ${<interpolation1>} b 
    c ${<interpolation2>} d 
    ${<interpolation3>} f""".trimIndent()

We would have a single LITERAL for the entire string template: varx5=LITERAL.
Therefore, we will not see duplications between <interpolation1>, <interpolation2>, and <interpolation3>.

We will also not see equivalent interpolation structures.
For example, given the following two strings:

var x1 = """"
    a $b c $d e $f ... $something
    """"
var x2 = """"
    a $b c $d e $f ... $somethingElse
    """"

We will see just two LITERAL: one for x1 and one for x2, instead of a sequence of LITERAL which would be the same, up to $something/$somethingElse

For both scenarios mentioned above, the probability that a duplication would be detected (i.e. at least 100 equal tokens on at least 10 different lines) seems close to zero, so it's better to treat the entire template as a literal to avoid issues like the one explained in the community post.

[leveretka]

In general, the approach looks good, thanks for having a look and fixing this.

I've just noticed 2 unused imports in the test.

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
90.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[antonioaversa]

@leveretka master is locked, so I'd let you merge the PR