Rethink how SBOMs are ingested / modelled

Right now, SBOMs require a Repo Key when importing them, which ties them quite strongly to the understanding of where that SBOM has come from.

However, at the time of ingestion, this isn't necessarily known.

Instead, we could:

• Remove platform, organisation and repo from sboms
• Create a sboms_metadata table, that can be LEFT JOIN'd to retrieve the Repo Key, if known
  • Alternatively sboms_repokey
• Relax the import sbom/import bulk requirements

This would have the follow-on of making i.e. platform a nullable field when querying via GraphQL, or in reports, so we'd need to consider this.

This then would also lead into #352 (closed)'s ability to import generic SBOMs.

Additionally, this will affect how SBOMs + ownership info shows up, which then may cause issues for uniqueness due to NULLs?

TODO:

• SBOM parsing pass filename, optional Repo Key
• Missing data gen
• Basename the filename?
• Validate the repo key in the DB
• allow multiple SBOMs