Aggregate BOMs cannot handle components with differing dependency trees in different modules

When processing aggregate BOMs it's possible to encounter projects which would cause the resolution of dependencies for a component to differ, for example
- during the resolution process, with different sets of transitive dependencies
- using dependency management
- using exclusions

An example of exclusion could be represented by the following dependency trees, where dependency_F has managed dependency_B to exclude dependency_E from the dependency graph

```
com.example.dependency_trees.exclusion:dependency_A:jar:1.0.0
\- com.example.dependency_trees.exclusion:dependency_B:jar:1.0.0:compile
+- com.example.dependency_trees.exclusion:dependency_C:jar:1.0.0:compile
| \- com.example.dependency_trees.exclusion:dependency_D:jar:1.0.0:compile
\- com.example.dependency_trees.exclusion:dependency_E:jar:1.0.0:compile
```
and
```
com.example.dependency_trees.exclusion:dependency_F:jar:1.0.0
\- com.example.dependency_trees.exclusion:dependency_B:jar:1.0.0:compile
\- com.example.dependency_trees.exclusion:dependency_C:jar:1.0.0:compile
\- com.example.dependency_trees.exclusion:dependency_D:jar:1.0.0:compile
```

An example of managing the versions could be represented by the following dependency trees, where dependency_E has managed the version of dependency_C to use version 2.0.0 instead of 1.0.0
```
com.example.dependency_trees.managed:dependency_A:jar:1.0.0
\- com.example.dependency_trees.managed:dependency_B:jar:1.0.0:compile
\- com.example.dependency_trees.managed:dependency_C:jar:1.0.0:compile
\- com.example.dependency_trees.managed:dependency_D:jar:1.0.0:compile
```
and
```
com.example.dependency_trees.managed:dependency_E:jar:1.0.0
\- com.example.dependency_trees.managed:dependency_B:jar:1.0.0:compile
\- com.example.dependency_trees.managed:dependency_C:jar:2.0.0:compile (version managed from 1.0.0)
\- com.example.dependency_trees.managed:dependency_D:jar:1.0.0:compile
```

Note this last example is also something that could occur based on the dependency resolution process, since the context of the roots would be different and could resolve to a different set of artifacts.

The aggregate SBOM should be able to represent all the valid dependency hierarchies, which means that each component with an alternative dependency hierarchy would exist multiple times (same purl but differing bom-ref/ref)

In both the above examples we would expect to see two components included for dependency_B with each related to a different reference (bom-ref) and a different dependency hierarchy (ref)

The issue names no files, tests, or entry points. Start by tracing aggregate BOM dependency resolution for the Maven plugin, using the exclusion and managed-version examples as cases; done means preserving every valid dependency hierarchy with separate components when the purl is shared.

Written by the indexing model from the issue text.