[FEATURE] Android & Kotlin-Gradle support (version catalogs, Google Maven repo)

**Is your feature request related to a problem? Please describe.**

Feluda's Java/Gradle backend (added in #217) scans `pom.xml`,
`build.gradle`, and `build.gradle.kts` and resolves transitive deps from
Maven Central. Plain **Kotlin-on-JVM** libraries already work, because they
use ordinary Maven Central coordinates.

However, a real **Android app** — or a modern Kotlin-Gradle project — is
significantly under-reported today, because three idioms that are now the
default in Android Studio / current Gradle aren't handled:

1. **Version catalogs aren't parsed.** Dependencies declared as
`implementation(libs.androidx.core.ktx)` (resolved from
`gradle/libs.versions.toml`) are missed entirely — the parser expects a
literal `"group:artifact:version"` string, not a `libs.*` accessor.
2. **Google's Maven repository isn't queried.** License + transitive lookup
only hits `repo1.maven.org` (Maven Central). AndroidX and
`com.google.android.*` artifacts live on `maven.google.com`, so they
resolve to `Unknown` and don't expand transitively.
3. **`platform()` BOM imports and Android/Kotlin configurations aren't
recognized.** Only `implementation` / `api` / `compileOnly` /
`runtimeOnly` / `annotationProcessor` / `compile` are matched —
`platform(...)`, `kapt`, `ksp`, `debugImplementation`,
`releaseImplementation`, etc. are skipped.

Net effect: plain Kotlin/JVM scans correctly, but an Android app's
dependency graph is largely invisible.

**Describe the solution you'd like**

Close the three gaps so Android and modern Kotlin-Gradle projects scan
accurately:

- **Version catalogs** — parse `gradle/libs.versions.toml` (`[versions]`,
`[libraries]`, `[bundles]`) and resolve `libs.*` accessors back to
`group:artifact:version` before license/transitive resolution.
- **Google Maven repo** — add `https://dl.google.com/dl/android/maven2/`
(a.k.a. `maven.google.com`) as a resolution source alongside Maven Central,
for both POM/license fetch and the transitive POM walk. Pick the registry
per coordinate (e.g. `androidx.*`, `com.google.android.*`) or try both.
- **Configurations & BOMs** — recognize `platform(...)` / `enforcedPlatform(...)`
imports and the broader configuration set (`kapt`, `ksp`,
`debug*/release*Implementation`, `testImplementation` handling, etc.).

**Describe alternatives you've considered**

- **Shell out to Gradle** (`./gradlew :app:dependencies`) — accurate and
handles all of the above for free, but requires the Gradle toolchain and a
buildable project, which is exactly why the rest of the Java backend
reconstructs the graph from published POMs instead. Could be offered as an
opt-in fallback for environments that have the toolchain, but should not be
the default.

**Additional context**

- Code pointers:
- `src/languages/java.rs` — `parse_gradle_dependencies` (configuration/coordinate
regex), `fetch_pom_content` (hardcoded to Maven Central),
`resolve_transitive_dependencies`.
- `src/languages/mod.rs` — `build.gradle(.kts)` detection.
- Surfaced as a follow-up in #217; documented there under "Known limitations".
- Scope note: plain Kotlin/JVM (Gradle or Maven) already works and is **not**
blocked on this.