Additional fields for `package_info` rule / `PackageInfo` provider

[adam-azarchs]

In the interest of not having everyone invent their own keys to add to ExperimentalMetadataInfo, I'm opening this issue to request a few more standardized fields for the PackageInfo provider.

Current fields, for reference:

rules_license/rules/providers.bzl

Lines 55 to 58 in 5b980ea

	"package_name": "string: Human readable package name",
	"package_url": "string: URL from which this package was downloaded.",
	"package_version": "string: Human readable version string",
	"purl": "string: package url matching the purl spec (https://github.com/package-url/purl-spec)",

Additional fields I would like to see are fields which are either commonly provided by package managers and potentially useful when generating reports in some contexts, or are required for some SBOM-like APIs, e.g. GitHub's dependency submission API. I don't much care to bike-shed the names of these fields as long as there's a place to put this information.

• homepage: The project's home page. This is often available for rust crates, npm packages, PyPi or conda packages, and so on, and is often helpful to a reviewer asking the question "what is this dependency for?"
• manifest: The manifest file (e.g. requirements.txt, go.mod, Cargo.lock) that declares this dependency. Used by the GitHub dependency submission API, and useful for "we need to update this dependency, which file do I need to edit?"
• ecosystem (definitely open to suggestions for a better name here): which package manager this package came from, e.g. debian, maven, conda, pypi, cargo, npm. Helpful for interpreting the package name (e.g. "is this numpy the python package or is this the rust crate?" Convenient for report-generating rules that want to sort things, but arguably redundant with first component of the purl (after the scheme).