Bad advice to remove Groovy extension modules

**Build scan link**
https://scans.gradle.com/s/npcpjijs3t23e

**Plugin version**
2.19.0

**Gradle version**
8.14.3

**JDK version**
17.0.10

**`reason` output for bugs relating to incorrect advice**
```plain
------------------------------------------------------------
You asked about the dependency 'org.apache.groovy:groovy-nio:4.0.27'.
You have been advised to remove this dependency from 'testImplementation'.
------------------------------------------------------------

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for compileClasspath

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for runtimeClasspath

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for testCompileClasspath

There is no path from root project to org.apache.groovy:groovy-nio:4.0.27 for testRuntimeClasspath

No compile-time usages detected for this runtime-only dependency.
```

**Describe the bug**
Libraries from which only Groovy Extension modules are used are advised to be removed.

**To Reproduce**
Steps to reproduce the behavior:
1. Have a project that uses Groovy 4 (either in the main code, or also in test code like when using Spock for tests)
2. Add a (`test`)`implementaion` dependency on `org.apache.groovy:groovy-nio:4+"
3. Use the extension module by having in the code for example `Path.of("/some/file").eachLine {}`

**Expected behavior**
Groovy extension modules should be `implementation` dependencies when they are used.
If Groovy is used in the default duck-typing mode, `runtimeOnly` would be sufficient to compile, but then the IDE looses the IntelliSense it has for those extension modules as that is only provided for compile-time dependencies.
If the respective code is using `@TypeChecked` or `@CompileStatic` it is even worse, because then it actually **is** necessary at compile-time.

I guess the analysis will not really be able to determine whether the extension module is used, without re-implementing the Groovy resolution logic and even then it might be wrong due to the duck-typing and meta-programming capabilities of Groovy.

So maybe the best way would be that if a library contains a Groovy extension module (`META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule`), then just accept if it is found in `implementation` even without it being detected as used by the analysis.

Or maybe a manual configuration like suggested in #1387 would also help here alternatively.

Start with the linked build scan and the `reason` output, reproducing the Groovy 4 `groovy-nio` case with `Path.of(...).eachLine {}`. Trace how dependency analysis handles `META-INF/groovy/org.codehaus.groovy.runtime.ExtensionModule`; done means extension-module dependencies are no longer incorrectly advised for removal, including the compile-time cases described.

Written by the indexing model from the issue text.