Add behavior to fallback to SBoM license scanning

What does this MR do and why?

Describe in detail what your merge request does and why.

This MR introduces a "fallback" behavior that allows for a project to transition to the new license database based license scanning. For context, this is required so that enabling the license_scanning_sbom_scanner feature does not immediately remove the licenses displayed for the project dependencies, and affect the outcomes of the license compliance policies set up.

To do this, the new license scanning implementation is only used with the following conditions:

1. The license_scanning_sbom_scanner feature flag is enabled.
2. The most recent pipeline with a cyclonedx report is newer than the most recent pipeline with a license_scanning report.
3. If a pipeline has both, then it will default to using the license_scanning report as the source of truth for licenses.

This has been outlined in Release Post: New License Compliance Scanner (gitlab-com/www-gitlab-com!119232 - merged) as well.

Closes #384936 (closed)

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

TBD

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Set up License Scanning (LS) and Dependency Scanning in a project.
2. Identify differences between licenses info provided by:
   • legacy implementation license-scanning job (Artifact Scanner)
   • new implementation using SBOMs and License DB (SBOM Scanner)
3. Enable feature flag for SBOM Scanner for that project.
4. Create an MR that target the default branch.
5. Check all license features. License info comes from LS artifacts.
   • Check License Compliance page.
   • Check Licenses tab of pipeline page.
   • Check MR page. There's no diff in the licenses.
6. In the MR, remove License Scanning from CI config.
7. Check MR page.
   • License info for the source branch comes from the SBOMs.
   • There's a diff in the licenses b/c it's compared with license info coming from LS artifacts.
8. Merge the MR into the default branch.
9. Check License Compliance page.
   • License info comes from the SBOMs.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #384936 (closed)