As part of #530, we want to make it possible to consume SBOMs without a
Repo Key, for instance if you've been provided an SBOM from a vendor, or
you're scanning a container image, which doesn't _necessarily_
correspond directly to a repository.

This performs a significant breakage, removing the Repo Key fields from
the `sboms` table, and instead requiring that the metadata be instead
stored in the `component_metadata` table and JOIN'd on the
`component_name` column.

This is a significant breaking change, so we mark this as a breaking
change, as well as bumping `compatible_since`.

This also:

- introduces a `path`, which provides a step towards #408 and better
  monorepo support
- involves fixing /a lot/ of queries that made assumptions about Repo
  Keys
- flags a number of places that will need to be improved in the future
  when we want to query for non-Repo Key results i.e. in advisories or
  other reports
- make it optional in `component_metadata`
- make it optional in `import sbom`
- introduce a better UX for Repo Key validation now it's optional when
  importing
- amending DB docs that reference the now-nonexistent `sboms.platform`
  (etc)
- making sure we pass through `sql.NullString`'s underlying `String` to
  `table.Row`s, otherwise we receive i.e. `{Example true}` which isn't
  helpful
- prioritise `component_metadata` over `owners` lookups, as the
  Component may have an owner but not a Repo Key (i.e. if it's vendor
  owned, or a Docker image)
- introduce a helper for UPSERTing, as it requires we check the row is
  already there (or so I think, I aimed to avoid #549)

Closes #530.