Consider a configuration option that turns off the special handling of 'test'

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

In standard JVM projects, additional source sets like `testFixtures` or `someCustomTestSuite` are all considered independent variants of a component (see #854). This means that they need to declare all their dependencies. And are not expected to "inherit" any dependencies from `main`.

The `test` source set behaves different though. Here the dependencies from `main` are inherited and if you redeclare a dependencies in test – e.g. `implementation("commons-io:commons-io")` and `testImplementation("commons-io:commons-io")` – the recommendation is to remove the `testImplementation(...)` dependency.

This corresponds to the traditional setup in Gradle, where the _Configurations_ of the test source set inherit from the _Configurations_ of the main source set. Which in turn is a behavior that more or less corresponds to the Scopes in Maven.

Conceptually, I think both perspective can makes sense:
1. If `test` contains unit tests that deeply reach into the production code (e.g. test protected methods), the tests can be seen as an _extension of the main code_ rather than an _independent variant of the component_.
2. If `test` contains functional tests that test the complete component through public interfaces, the tests can be seen as an _independent variant of the component_.

**Describe the solution you'd like**

If we want support defining "non-unit" tests in `test`, it would be great to have a configuration option for this like:

```
dependencyAnalysis.issues {
testAsStandardSourceSet.set(true)
}
```

**Describe alternatives you've considered**

This is a nice to have I think. You can still get the desired setup by putting non-unit tests into other source sets (e.g. `functionalTest` or `integrationTest`) for which you automatically get the "independent variant" (2) behavior.

**Additional context**

I filed this issue to document and explain this behavior. And to have something to link to in projects that have to make setup decisions because of this. This issue can be closed if the _described alternative_ is considered to be sufficient.

The issue names no files, tests, or entry points. Start by tracing how the plugin handles the special `test` source set and its dependency inheritance, then assess how the proposed `testAsStandardSourceSet` option would affect the existing behavior. Done means the configuration semantics are defined and covered by appropriate tests, if the feature is accepted.

Written by the indexing model from the issue text.