Fix same-config change advice crash in KMP projects

[NikolayMetchev]

Summary

• Fixes Change advice cannot be from and to the same configuration (androidMainImplementation) in KMP project #1649: buildHealth crashes with "Change advice cannot be from and to the same configuration (androidMainImplementation)" in KMP projects with both Android and JVM targets
• In StandardTransform.simplify(), when a matching add+remove pair has the same configuration (from == to), they now cancel each other out instead of crashing
• Added a functional test that reproduces the exact scenario from the issue

Test plan

• New functional test SameConfigKmpProject reproduces the crash (verified it fails without the fix)
• All existing KMP tests pass (11/11 including 3 new)
• Unit tests pass

🤖 Generated with Claude Code

[autonomousapps]

I am not certain this is the correct solution. If we get to this point with from and to being the same configuration, that implies something flawed in the analysis. Simply not crashing here might hide a deeper flaw.

[NikolayMetchev]

You're right — the original fix was masking a deeper flaw. I've pushed a new commit that addresses the root cause.

Root cause: KmpSourceKind is a data class whose equality included compileClasspathName and runtimeClasspathName. These fields are constructed via two different paths:

1. KmpSourceKind.of(compilation) — built from a real Kotlin compilation; for Android, this yields e.g. debugCompileClasspath
2. ConfigurationNames.sourceKindFrom("androidMainImplementation") — inferred from a config name; yields androidMainCompileClasspath

Because these differ, usage and declaration SourceKinds never matched in computeAdvice(). This caused both ofAdd and ofRemove to be generated for the same configuration, which then crashed in simplify() when it tried to create a change advice with from == to.

Fix: Override equals/hashCode/compareTo in KmpSourceKind to compare by name only. KMP source set names are unique identifiers; the classpath names are derived values that don't add discriminating power and shouldn't participate in equality.

The prior symptomatic guard in simplify() has been reverted. I've also added a unit test (StandardTransformTest) that directly reproduces the IllegalArgumentException without requiring the Android SDK, making it easy to verify the red→green cycle.

[autonomousapps]

See #1673

Also, please note that I have recently added a code of conduct, and now LLM-generated content is strictly forbidden for both issues and PRs.