[Feature request] Improved transparency of managed dependencies (Maven, NPM, etc.) and their licenses.

Issue Type: Feature Request / Improvement to existing feature

**Business Case:**
Dependencies have license terms that can affect the core licensing position of a project, or simply be “license incompatible” to the component’s declared license. The most obvious example being a permissively licensed component having a GPL dependency.

Therefore, it is important to make license information of managed dependencies accessible to ClearlyDefined users.

When we speak of “managed” dependencies, we are referring to dependencies that may not actually be included in a project’s source code distribution but are instead automatically downloaded at a later point in time using technologies like NPM and Maven.

Managed dependencies may not directly be a part of the project’s source tree to start off with, but when a user builds a project themselves or consumes pre-built binaries, these dependencies are downloaded from remote repositories and are considered as a direct part of the project.

ClearlyDefined already extracts some basic information about direct managed dependencies from the project’s package manifest files during harvest. However, this information is not easily accessible to users and not all essential information is extracted.

**Feature Description:**
Surface whatever data is already available regarding direct managed dependencies (name, version, and scope) plus the corresponding license data and make it easily accessible to all users on the component’s definition.

**Requirements:**

1). Extend the “dependencies[{}]” section under the raw harvested data to include the dependency’s applicable license. Currently, the following data is available:

- Dependency Name
- Dependency Version
- Dependency Scope

We’d need to add an additional field called _“license”_ to be able to include license details for each dependency. The license data could come from a supported central repository such as NPM or Maven, depending on which one is being used.

2). Surface the existing package management metadata currently available under the raw “Harvested data” tab and normalize it.

Below is a sample of data as it is **currently** made available and presented for a [Maven component](https://clearlydefined.io/definitions/sourcearchive/mavencentral/org.jbpm.contrib/mavenembedder-workitem/7.9.0.Final):


Below is a sample of data as it is **currently** made available and presented for an [NPM component](https://clearlydefined.io/definitions/npm/npmjs/-/base-options/0.6.0) (there are separate sections for each scope).


Below is a sample of data as it is **currently** made available and presented for a [Ruby component](https://clearlydefined.io/definitions/gem/rubygems/-/stretchy/0.3.0) (again, there are separate sections for each scope):


A nice improvement would be to create a **new tab** next to Harvested data, perhaps called “Dependency data”.

This tab would provide a standardized, human-readable summary of dependency information if any exists for a given component and would also include the license detail. The underlying data could be obtained from the package manifest files themselves as illustrated in the examples above, or by using the package repository's API (npmjs.org, etc.). In the case such API is not available, or results differ greatly from the contents of package manifest file, the package manifest file could be used as the primary data source.


Alternatively, instead of putting the Dependency data as a tab under the “Raw data” area, we could put it in its own section in between “Files” and “Raw data”.


All dependency identifiers should follow the Package URL (PURL) format outlined here: [https://github.com/package-url/purl-spec](https://github.com/package-url/purl-spec). This format is consistent with the rest of ClearlyDefined.

And to ensure dependency versions are consistent and easy to understand, conventions such as those used in [Semantic Versioning](https://semver.org/) (semver) should be adopted where possible to normalize version constraints when we display them to users (package_x ^1.0.0, etc.)