Support multiple instances of the same Checkstyle check with different IDs

[rdiachenko]

Description

Checkstyle allows configuring the same check multiple times with different IDs and configurations. For example:

<module name="TreeWalker">
  <!-- Strict check for production code -->
  <module name="FinalLocalVariableCheck">
    <property name="id" value="strict"/>
    <property name="validateEnhancedForLoopVariable" value="true"/>
  </module>

  <!-- Lenient check for test code -->
  <module name="FinalLocalVariableCheck">
    <property name="id" value="lenient"/>
    <property name="validateEnhancedForLoopVariable" value="false"/>
  </module>
</module>

Current Behavior

1. Maps checks by their CheckstyleCheck enum value (class name only), ignoring the id attribute
2. Overwrites previous configurations when multiple instances of the same check exist
3. Groups all violations from the same check type together, regardless of which check instance reported them

This means violations from strict and lenient are:

• Treated as the same check
• Fixed using only the last loaded configuration
• Cannot be distinguished or fixed differently

Expected Behavior

1. Preserve the id attribute for each check instance
2. Store multiple configurations for the same check type (keyed by ID)
3. Match violations to their specific check instance using the id from the report
4. Apply the correct configuration when fixing violations from each instance

Starting Point

1. Change CheckstyleCheck enum or create a new identity class that includes both check type and ID
2. Update ConfigurationLoader to preserve multiple instances with their IDs
3. Update parsers (XML/SARIF) to extract the check ID from violation reports
4. Update CheckstyleRecipeRegistry to match violations to the correct check instance

[Anmol202005]

@rdiachenko

<module name="FinalLocalVariableCheck" >
    <property name="id" value="final-strict"/>
    <property name="validateEnhancedForLoopVariable" value="true"/>
</module>

The ID must be used a property, i guess i am not missing anything.

and in the current implementation.
no checks will be fixed if the id is mentioned in properties. since the violation report then mention the id not the actual check.

so we need to find a way to extract the checkname from the id. I guess that solves the issue.

[rdiachenko]

The ID must be used a property, i guess i am not missing anything.

yes, I updated examples in the description

so we need to find a way to extract the checkname from the id.

no, id is an opitonal part of check's identity, we can't extract module's name from it. We should use module's name + id (if it is present) as module's identity and map it to a corresponding configuration and recipe. This means we may need to replace existing enum with the class, which will be a compound key in the CheckstyleRecipeRegistry