Module structure (JVM) advice ignores build-type source splits

**Plugin version**
3.12.0

**Gradle version**
Any currently supported version (8.11+); the behavior is not Gradle-version-specific.

**JDK version**
Not relevant to this issue (reproduced on JDK 17 and 21).

**(Optional) Android Gradle Plugin (AGP) version**
Any currently supported AGP; reproduced with `com.android.library` modules.

**Describe the bug**
The module-structure advice ("This project uses limited Android features and could be a JVM project." / "...should be a JVM project.") does not take build-type source sets into account.

An Android library module that uses no Android features in its `main` source set, but which defines build-type-specific source sets (e.g. a `debug` and/or `release` source set), is still advised to be converted to a plain JVM/Kotlin module. That conversion is not possible: build types — and the per-build-type source sets they enable — are an Android Gradle Plugin construct with no equivalent in a plain `java-library` / `org.jetbrains.kotlin.jvm` module. Following the advice would drop those build-type source sets.

The plugin already captures the relevant signal: the `android_score` entry in `moduleAdvice` exposes a `hasBuildTypeSourceSplits` boolean, and it is `true` for the affected modules. So the information is collected but is not factored into the could/should-be-JVM determination — modules with `hasBuildTypeSourceSplits = true` are still emitted as JVM-conversion candidates.

**To Reproduce**
Steps to reproduce the behavior:
1. Create an Android library module (`com.android.library`) that uses no Android features in `src/main` (no resources, no `android.*` / `androidx.*` API that requires AGP, no `BuildConfig`, etc.).
2. Give it a build-type-specific source set, e.g. a `src/debug` source set with build-type-specific code, so the module genuinely relies on build types.
3. Run `buildHealth` (or the module-structure analysis for that module).
4. Observe the advice: "This project uses limited Android features and could be a JVM project." The corresponding `android_score` `moduleAdvice` shows `hasBuildTypeSourceSplits = true`.

**Expected behavior**
A module that has build-type source splits should not be advised to become a plain JVM module, since build types / per-build-type source sets cannot be represented in a JVM module. `hasBuildTypeSourceSplits = true` should disqualify a module from the "could/should be a JVM project" advice (or at minimum weigh strongly against it). The same reasoning applies to product-flavor source sets, which are likewise AGP-only.

**Additional context**
The distinction matters in practice: when separating genuine JVM-conversion candidates from false positives, the only differentiator for some modules is precisely that they declare build-type (or flavor) source sets while having no Android API usage in `main`. Since that signal is already collected (`hasBuildTypeSourceSplits`), honoring it would remove a class of non-actionable advice. This appears distinct from #1206 (which concerns modules that cannot drop Android *dependencies*).

Run buildHealth on the Android library scenario described and inspect the module-structure analysis, especially the android_score and moduleAdvice data. Trace where hasBuildTypeSourceSplits is considered in the could/should-be-JVM determination. Done means modules with build-type source splits no longer receive JVM-conversion advice, with the behavior covered by the relevant analysis test if one is present.

Written by the indexing model from the issue text.