VCIO-next: Do not merge AffectedPackage while importing AdvisoryV2

[keshav-space]

Do not merge AffectedPackage while importing AdvisoryV2. Current AdvisoryV2 models have affecting_packages and affected_package M2M fields, and while populating V2 advisory importers are merging different AffectedPackage into a single AffectedPackage and using the merged AffectedPackage to populate affecting_packages and affected_package, which is problematic, see the example below.

Lets take a look at this GHSA GHSA-h4j7-5rxr-p4wc for Microsoft.Build.Tasks.Core

Affected versions	Patched versions
>= 15.8.166, <= 15.9.20	15.9.30
>= 16.0.461, <= 16.11.0	16.11.6
>= 17.0.0, <= 17.8.3	17.8.29
>= 17.9.5, <= 17.10.4	17.10.29
= 17.11.4	17.12.36
= 17.12.6	17.13.26
= 17.13.9	17.14.8

If we merge this different range into one we will not be able to report appropriate fixed version for an affected package with absolute certainty. The problem gets even more complicated when we have advisory with multiple package each having more than one set of affected and fix range, see GHSA-266m-wp2v-x7mq
This is also a regression from existing Advisory model, where we keep list of AffectedPackage in JsonField.

• We should introduce ImpactedPackage model with base_purl, affected_package_vers affected_packages, fixed_package_vers and fixed_packages. And an advisory can point to multiple ImpactedPackage.
• Instead of merging AffectedPackage importer should create ImpactedPackge from AffectedPackage data.
• Also Importer should not resolve vers range into concrete package version during import instead this should be handled in separate pipeline.