feat(third-party-integrations): generic dispatcher

[migmartri]

Continuation of #38

TLDR; The server side integrations code is now fully generic and decoupled from the dependency-track implementation. It also works for attestation-based integrations which we expect to implement soon #28

It defines a generic dispatcher (and removes previous dependency-track specific code).

The fanout dispatcher is called when an attestation is received and performs two phases

1 - Integrations configuration preparation (integrationsMap)

• Load the integration attached to the workflow
• Calculate what kind of inputs these want, material type (i.e CDX SBOM) or attestation (thanks to this refactor(integrations): dynamic integrations loader #141)
• For each one it makes sure to collect all the context required for a plugin to be executed. Registration and attachment configurations, credentials and the actual input)

2 - Attestation analysis, materials extraction and integration execution

The next step is for the dispatcher to analyze the kind of materials is contained in the received attestation and match them with the previously computed map.

• For each material type we check if there is any integration waiting for it, if so, we download it (once) and enqueue an execution refactor(integrations): dynamic integrations loader #141 (this part will eventually be moved to a background processing system [fan-out integration] add resiliency to firing mechanism #39)
• In addition, integrations can be configured to listen to attestation input types, we sent the attestations to those directly as well.

[danlishka]

LGTM!