As noted in #525, if you have run:

    dmd [...] import renovate [...]
    dmd [...] db generate dependency-health

You will receive a single entry per dependency in `dependency_health`
i.e.:

    github.com/google/uuid    gomod     5.012345678903459    # stale

Then, if you were to manually scan the repo with `scorecard` and import
that data in with:

    dmd [...] import scorecard [...]

This then results in multiple entries in `dependency_health` i.e.:

    github.com/google/uuid    gomod     5.012345678903459    # stale
    github.com/google/uuid    golang    7.099999904632568    # newer

Then, when looking at the advisories that are present, or `JOIN`ing the
tables, we will receive the stale data.

To fix this, we can instead store, and solely use, the `package_type`,
which we've derived. This was already what we were doing, just without
the intermediate step of storing the `package_type` in the database.

One area this could cause concern is if the version of `dmd` used to
create the database + import data is different to the version then used
to generate dependency health / to import the scorecards, and there may
be a difference between the derived data in the database. However, this
is fairly non-standard.

This is a breaking change due to the definition in
https://dmd.tanna.dev/concepts/compatible-since/:

> Renaming of a column

In which we've renamed the `package_manager` to `package_type`, so need
to appropriately note that this is a breaking change.

Closes #525, and a step towards #446.