<commit_before>Improved dependency resolution reporting

# Use cases.

1. Priority use case: It is hard to figure out why Gradle picks up version X of certain dependency because the dependency report
    only includes the version information *after* conflicts have been resolved.
2. User diagnoses dependency resolve failures
    (with a possible implementation being that the reporting is robust in the face of failures)
3. User views actual class paths
    (e.g currently the reports only show module dependencies.
    It should show external dependencies, self-resolving dependencies, tweaks to sourceSets.main.compileClasspath, etc).
4. User knows why certain dependencies appear / not appear in the graph (e.g. consider exclusions)

# User visible changes

1. At minimum the dependencies report should include information of the 'asked' dependency version
Instead of raw version we can print something like: 1.0->3.0. Mock up:

<pre>
testCompile - Classpath for compiling the test sources.
+--- root:a:1.0 [default]
|    \--- foo:bar:1.0->3.0 [default]
\--- root:b:1.0 [default]
     \--- foo:bar:3.0 [default] (*)
</pre>

2. Consider a new console report that traverses the graph the opposite way.

Not sure how to call this report.
The idea is to traverse the graph the other way and print information who depends on a given dependency.
This report is useful to track where the given version of some dependency was picked up from in case of conflict resolution.
This report could drive some conveniences to our DependencyGraph API.

# Integration test coverage

1. Scenarios:

* conflicting direct dependencies
* conflicting direct & transitive dependency<commit_msg>Updated the spec after the pairing session.<commit_after>Improved dependency resolution reporting

# Use cases.

1. Priority use case: It is hard to figure out why Gradle picks up version X of certain dependency because the dependency report
    only includes the version information *after* conflicts have been resolved.
2. User diagnoses dependency resolve failures
    (with a possible implementation being that the reporting is robust in the face of failures)
3. User views actual class paths
    (e.g currently the reports only show module dependencies.
    It should show external dependencies, self-resolving dependencies, tweaks to sourceSets.main.compileClasspath, etc).
4. User knows why certain dependencies appear / not appear in the graph (e.g. consider exclusions)

# User visible changes

1. The dependencies report should include information of the 'asked' dependency version
Instead of raw version we can print something like: 1.0->3.0. Mock up:

<pre>
testCompile - Classpath for compiling the test sources.
+--- root:a:1.0 [default]
|    \--- foo:bar:1.0->3.0 [default]
\--- root:b:1.0 [default]
     \--- foo:bar:3.0 [default] (*)
</pre>

2. A brand new report that traverses the graph the opposite way.

Mock up:
<pre>
com.linkedin.util:util-core - selected version does not exist in the dependency graph.

com.linkedin.util:util-core:4.0.7
\--- com.linkedin.sharedlibs:configuration-repository-impl:1.3.30
     \--- com.linkedin.sharedlibs:lispring-lispring-core:1.3.30
          \--- com.linkedin.container:container-http-impl:3.0.24
               \--- com.linkedin.container:container-rpc-impl:3.0.24

com.linkedin.util:util-core:2.4.6 -> 4.0.7
\--- com.linkedin.cfg2:cfg:2.8.0
     \--- com.linkedin.sharedlibs:lispring-lispring-core:1.3.30
          \--- com.linkedin.container:container-http-impl:3.0.24
               \--- com.linkedin.container:container-rpc-impl:3.0.24
</pre>

The idea is to traverse the graph the other way and print the dependee path for a given dependency.
This report is useful to track where the given version of some dependency was picked up from in case of conflict resolution.
This drives some conveniences to our DependencyGraph API.
There should be some simple way to run the report from the command line.
While doing that consider adding support for selecting configuration for the regular 'dependencies' report from command line.

# Integration test coverage

1. Scenarios:

* conflicting direct dependencies
* conflicting direct & transitive dependency
{'fraction_non_alphanumeric': 0.08022922636103152, 'fraction_numerical': 0.019818529130850047, 'mean_word_length': 3.7765108323831242, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 14, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2550353', 'n_tokens_mistral': 1145, 'n_tokens_neox': 1107, 'n_words': 507}