Generate NuGet PURL's

[KendallHarterAtWork]

Summary

If merged this pull request will generate PURL's for NuGet packages as an additional name in the SBOM.

Proposed changes

This also runs init_hook for hooks implementing establish_relationships during the generate command, which was not done previously.

[github-actions]

✅ No SBOM Changes Detected

_{For commit 0ac6122 (Run 29793029091)
Compared against commit fb56cd8 (Run 29785707536)}

[nightlark]

• Some extra guards/checks against potential exceptions, stylistic single/double underscore naming change.
• Add a user config option to opt-in to network requests to nuget.
• Add caching for results from NuGet API requests to eliminate repeated requests for the same info, and a network timeout to avoid hanging if the server is unresponsive.

I'm thinking in the future maybe this could also leverage any results from dapper that might be in the metadata, which could allow for an "offline" fallback, or reduce the number of NuGet API requests that are needed.

For a future change outside of this PR, we might want to add a new hook type that this could later be updated to use along the lines of
enrich_software(sbom: SBOM, software: Software) -> None that would be called once per software entry (perhaps after establishing relationships) rather than once for each metadata entry, and would be intended for plugins that are looking at potentially many metadata entries and relationships at the same time.

[nightlark]

Fixed a small regression that prevented the version check from working, and noticed that the metadata["FileInfo"]["ProductVersion"] is often better for lookups than the assembly version (or any of the other version fields in file info.

Quite a few frequently used packages will add fourth version number components that make the NuGet lookup not find a matching version. "ProductVersion" on the other hand appears to always match the version numbers that appear on NuGet including pre-release components (after removing any trailing +<hash> from it). I suspect "ProductName" might be the best option for looking up a matching package (possibly even in cases where the file name != package name), if we had some way to map it to the package name to search for on NuGet.