Add composite build support

[shanshin]

It is necessary to understand whether it is possible to add support for composite builds in Kover.

If this is feasible, then it is necessary to think through the ways of implementation.

[gmazzo]

Elaborating on this, what I meant at #598:

Variants are there, it's seems to a matter of the internal plugin resolution strategy.

By this, what I meant is that you are already exposing an outgoingVariant per module with the totals of the module, that you later use for the aggregation report (similar to that JaCoCo Report Aggregation works).

The issue to me, based on a quick source code inspection, as that you are managing dependencies linking by hand, instead of letting these artifacts to expose them.

I'm assuming this is some kind of intentional, as you also have some kind of dual behavior of "this module only" or "this module and its dependencies" when collecting the overage data.

Assuming my assessment is correct, what I'd suggestyou is to:

1. Let outgoingVariant artifacts to properly expose they builder dependencies .builtBy(test) for instance.
2. Expose two "total" outgoingVariants, one with dependencies and another without it to keep supporting the dual behavior, each one with an extra attribute to distinguish them: i.e. kotlinx.kover.withDependencies: true|false

[shanshin]

I'm assuming this is some kind of intentional, as you also have some kind of dual behavior of "this module only" or "this module and its dependencies" when collecting the overage data.

This is not quite true, this is done for the reason that the report options in the projects may vary. For example, in the current project there has variant debug, and dependency has only jvm. Hence, when creating custom options, a duality appears: look for this option only in the current module, or in all kover dependencies.
If there is no report variant in dependency, then a dependency resolution error may occur, so for simplicity, this approach is used.

Let outgoingVariant artifacts to properly expose they builder dependencies .builtBy(test) for instance.

It's already exposed, artifact is built by koverGenerateArtifact task (koverGenerateArtifactFoo), and it, in turn, depends on test tasks.

---

The problem of composite build support is more design-based, because Kover artifacts were invented to work within a single build.
They contain relative paths to all the necessary data, but we need to get the data itself from another build: the contents of binary reports, all the application class-files, all the sources.

[shanshin]

This task will be taken into account when migrating to Kotlin Gradle Plugin.

In the future, it will be moved to the Kotlin task tracker, or closed if it loses relevance.