Improve usability in pre-compiled scrip plugins by merging DependencyAnalysisExtension and DependencyAnalysisSubExtension

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

If you define a pre-compiled script plugin, the below does not work:

```
plugins {
id("java")
id("com.autonomousapps.dependency-analysis")
}

dependencyAnalysis { issues { onAny { severity("fail") } } }
```

This is, because the **type** of `dependencyAnalysis { ... }` depends on whether you use it in a root project (`DependencyAnalysisExtension`) or a subproject (`DependencyAnalysisSubExtension`). When a pre-compiled script plugin is compiled, the configuration code is executed out of context of a real project. The compilation uses a kind of artificial project for this. In this phase, DAGP **always** thinks that it is in a root project. This can have the following effects:
- The script does not compile, because you attempt to use a construct only available in `DependencyAnalysisSubExtension`
- If compilation is successful, you get a ClassCast exception inside the code generated by Gradle when the plugin is used inside a subproject (which may look like a bug in the plugin to users).

**Describe the solution you'd like**

Because the pre-compiled script plugin never knows the context it will be applied in later, the only solution I see for this is to **not** register different types as `dependencyAnalysis` depending on the context.
I think the functionality of both types could be merged into one. The details would have to be sorted out for the constructs that are currently not available in one of the contexts.
For instance, there will then always be a `all {}` and `project(...) {}` selector, even if you are in a subproject. These could be no-ops, or can apply things to subprojects-of-a-subproject. Or/and give an error if there are no subprojects.

**Describe alternatives you've considered**

You can use `configure` instead of `dependencyAnalysis` when you know in which context your pre-compiled script plugin will be used and choose the correct type there:

```
plugins {
id("java")
id("com.autonomousapps.dependency-analysis")
}

configure { issues { onAny { severity("fail") } } }
```

**Additional context**

The example used in a project:
https://github.com/jjohannes/gradle-project-setup-howto/blob/main/gradle/plugins/src/main/kotlin/org.example.gradle.check.dependencies.gradle.kts

This is a usability improvement for certain setups. Maybe it also makes the configuration DSL more clear in general, as it can be confusing that the same notation allows for different things in different contexts (but I don't know if that is really the case here). The "workaround" is working well. This does not need to be handled with high priority.

Start by reading DependencyAnalysisExtension and DependencyAnalysisSubExtension, then reproduce the pre-compiled script case using the linked gradle-project-setup-howto example. Determine how their DSLs can be unified while preserving existing root and subproject behavior. Done means dependencyAnalysis compiles and configures correctly in pre-compiled script plugins used in either context, without generated-code ClassCastException.

Written by the indexing model from the issue text.