SONARJAVA-6876 S2479 Reduce noise by suppressing on strings that are most likely generated - #6061

Code Review: Reduces noise in S2479 by adding `GeneratedStringLiteralRecognizer` to suppress string literals likely generated in Kotlin annotations, with `ControlCharacterInLiteralCheck` updated to ignore recognized generated literals.
  
  Consider moving the `isGenerated` check behind the regex match to avoid walking the parent chain for every literal on the hot path. Also add a `withoutSemantic()` test case and move the shadowing scenario to a file without `kotlin.Metadata` imports so it validates in both semantic and non-semantic modes; a text-block case would also improve coverage.

1. 💡 Performance: isGenerated runs for every literal before the cheap regex check
   Files: java-checks/src/main/java/org/sonar/java/checks/ControlCharacterInLiteralCheck.java:68-82, java-checks/src/main/java/org/sonar/java/checks/helpers/GeneratedStringLiteralRecognizer.java:52-66

   `isGenerated` is invoked as the first statement of `visitNode`, so for every string/char literal/text block in every analysed file it walks the parent chain up to the compilation-unit root (the `while` loop only stops on an `ARGUMENTS` parent, which the vast majority of literals never have), and in the unresolved-type case it additionally runs `concatenate` plus a full import scan up to three times. The suppression is only needed for the tiny fraction of literals that actually contain a control character, so moving the call behind `matcher.find()` yields identical behaviour with strictly less work on the hot path of a rule that subscribes to all literals.

   Fix (Only consult the recognizer when an issue is about to be reported):
   @Override
   public void visitNode(Tree tree) {
     LiteralTree literal = (LiteralTree) tree;
     String literalValue = LiteralUtils.getAsStringValue(literal);
     Matcher matcher;
     if (allowTabsInTextBlocks && tree.is(Tree.Kind.TEXT_BLOCK)) {
       matcher = CONTROL_CHARACTERS_WITHOUT_TABS_PATTERN.matcher(literalValue);
     } else {
       matcher = CONTROL_CHARACTERS_PATTERN.matcher(literalValue);
     }
     if (matcher.find() && !GeneratedStringLiteralRecognizer.isGenerated(literal)) {
       reportIssue(literal, String.format(MESSAGE_FORMAT, literalValue.codePointAt(matcher.start())));
     }
   }

2. 💡 Quality: No withoutSemantic() test; shadowing case only covers semantic path
   Files: java-checks/src/test/java/org/sonar/java/checks/helpers/GeneratedStringLiteralRecognizerTest.java:32-46, java-checks-test-sources/default/src/main/java/checks/helpers/GeneratedStringLiteralRecognizerSample.java:3, java-checks-test-sources/default/src/main/java/checks/helpers/GeneratedStringLiteralRecognizerSample.java:32-41

   The new test class only runs with the full classpath and with `withClassPath(List.of())`, not with the repo-mandated `withoutSemantic()`. `InternalCheckVerifier.scanFiles` skips `enableSemanticWithProjectClasspath` when `withoutSemantic` is set, so in that mode even the source-declared nested `@interface Metadata` has an unknown `symbolType`; `isAnnotationType` then falls back to simple-name matching and finds `import kotlin.Metadata` in the same file, so `ShadowedMetadataSample.Annotated` (line 38, marked `// Compliant`) would be classified as generated. The shadowing scenario the sample claims to cover is therefore only validated on the resolved-type path. Add the `withoutSemantic()` test and put the shadowing case in a file that does not import `kotlin.Metadata` so it is meaningful in both modes; also add a text-block case, since `isGenerated` explicitly accepts `Tree.Kind.TEXT_BLOCK` but no text block appears in the sample.

   Fix (Add the conventional without-semantic test and move the shadowing case to its own sample file that does not import kotlin.Metadata):
   @Test
   void test_without_semantic() {
     CheckVerifier.newVerifier()
       .onFile(mainCodeSourcesPath(TEST_FILE))
       .withCheck(new TestCheck())
       .withoutSemantic()
       .verifyIssues();
   }