Add TargetFramework awareness to NuGet detector

[ericstj]

This PR does 3 things.

1. Adds TargetFramework to NuGet package references. This can be useful when querying component data to understand if components are used in a place where a vulnerability applies.
2. Adds framework package handling. The .NET SDK will do conflict resolution and drop assets from packages that overlap with the framework. NuGet is planning to do the same https://github.com/NuGet/Home/issues/7344 but until then, it's beneficial to have component detection duplicate some of this logic. When a package is identified as overlapping with the framework we'll treat it as a Development Dependency so that it might be auto-dismissed.

• .NETFramework projects do not get this - .NETFramework does not participate in conflict resolution by default. Even when enabled framework assemblies can be bypassed using bindingRedirects, or avoiding references to them. Due this fragility it's not safe to apply framework package rules to .NETFramework.
• packages.config usage is also excluded since it precludes SDK conflict resolution (and is also only used on .NETFramework projects).

3. Recognizes ExcludeAssets="Runtime" usage as a Development Dependencies.

A couple notes:

1. I reused Development Dependency rather than plumbing a new concept.
2. I only mapped data for the Microsoft.NETCore.App - the default shared framework. We could consider doing the same for Microsoft.ASPNETCore.App and Microsoft.WindowsDesktop.App but we'd need to plumb the reference information out of the assets file - currently that's not read and I'm not aware of a supported NuGet API for reading it (though it is present under project/frameworks/<framework>/frameworkReferences/<name>
3. I've tested this manually on a simple project and a more complex repository. It's doing what I expect and I see the targetFramework information added to the component in the ScanManifest. I noticed that development dependencies are labeled as such if all references to the component are development dependencies. If any reference is not a development dependency then the component is not labeled as a development dependency.
4. I need to add automated tests for this.
5. I added the tool findLastPackage that I used to generate the sources for the framework lists - but this is just for reference. I don't intend to check this tool in.
6. Maybe we could even do more with CG here to mark libaries as development dependencies when all their runtime assets are excluded. This technique is common for plugins and excluding them in this way would be beneficial for folks even when not in a framework dependency case. I'll add this.