refactor: accept provenance data in artifact pipeline check

[behnazh-w]

Refactoring the artifact pipeline detection check

• Renames mcn_infer_artifact_pipeline_1 to mcn_find_artifact_pipeline_1.
• This check can support all the package registries now.
• Modifies the check fact table schema by adding new columns and allowing some existing columns to be nullable. This change enables us to store the reasons for check failures, such as when a GitHub workflow run is deleted, which may result in some previous columns lacking values.
• Improve the heusristics, e.g., if an artifact is published before the corresponding code is committed, there cannot be a CI pipeline that triggered the publishing.
• This check depends on the deploy command identified by the mcn_build_as_code_1 check. If a deploy command is detected, this check will attempt to locate a successful CI pipeline that triggered the step containing the deploy command.
• When a verifiable provenance is found for an artifact, we use it to obtain the pipeline trigger. Otherwise, we use heuristics to find the triggering pipeline.

Improvements to mcn_build_as_code_1

• If a provenance is found, we obtain the workflow that has triggered the artifact release.
• Add support for Reusable GitHub Actions that perform automatic deployment. Since we do not analyze the external Reusable GitHub Actions, we use an allow list of approved Actions.
• A new function, infer_confidence_deploy_workflow is added to BaseBuildTool to infer the confidence for such Reusable workflows.

The store_inferred_build_info_results function

• Renamed store_inferred_provenance to store_inferred_build_info_results.
• To avoid confusion, we avoid using the term inferred provenance here and instead simplify store build related information in the context object provided to checks.
• Instead of using CIInfo["provenances"] for inferred build command analysis results, we use a new field: CIInfo["build_info_results"].

Provenance Extractor

• New abstractions added to the provenance extractor to reuse the logic for extracting information such as ProvenanceBuildDefinition and ProvenancePredicate. With these new abstractions, we don't need to hardcode the expected buildType value while processing a provenance.

find_publish_timestamp

• Added an API that can obtain the artifact timestamp for all the supported package registries.
• By default we use deps.dev to obtain the timestamp except for Maven artifacts because we have observed that Maven Central has more accurate results.
• Decoupled the Maven Central search API from the repository, making the hostname fully configurable to enable offline testing with a localhost server.

Tutorial and integration tests

• Changed the Detecting a malicious Java dependency uploaded manually to Maven Central tutorial to Detecting Java dependencies manually uploaded to Maven Central
• Used log4j-core artifact instead of guava, which has an automated deployment workflow.
• Fixed the integration tests and added a new one for log4j-core.

[tromai]

I have finished my review. Thanks.
Overall, there isn't any major changes needs. Most of my comments are for minor improvements/nit picking.

[tromai]

Except from a small question in #872 (comment), my approval still holds. The PR could be merged as it.