Split DB v6 Curator object

[wagoodman]

This splits out a portion of work from #2125 , specifically around splitting the DB curator object into separate use cases (see that issue for details/motivations). Here's a suggested starting point after #2124 is completed:

grype/db
├── legacy
│   └── distribution                    # support v1-5 distribution concerns from #2124
│       ├── curator.go
│       ├── listing.go
│       ├── metadata.go
│       └── status.go
├── v1/
├── v2/
├── v3/
├── v4/
├── v5/
└── v6/
    ├── distribution
    │   ├── client.go                 # manages searching for and downloading a DB
    │   ├── history.go                # (new) history.json shape
    │   └── latest.go                 # latest.json shape
    ├── installation
    │   ├── database_curator.go       # manages accessing an installed DB
    │   └── status.go                 # supports DB status
    ....

There are two objects to really create and refine:

• grype DB distribution client: handles downloading an installed DB
• installation DB curator: handles accessing an installed DB and managing it's lifecycle (including update, using the distribution object)

(these are probably separate PRs! 🙏 )

The DB curator should take the following considerations:

• validate the DB by checksum on initialization. Change application config to default to checking the DB checksum on startup to default to 'true' instead of 'false' as it is today. If the curator is configured to not check the checksum it must at least check for the existence at initialization.
• Owns the "DB update" logic, using the distribution to simply download.
• Owns the core DB status definition
• Activating a new DB should be a move, not a copy (but the tmp for this download should reside within the destintion dir to prevent cross filesystem moves)

The DB client should take the following considerations:

• pivot from an "update" concern to a "download" concern, being passed exactly what description to download
• should be able to identify a later DB description when given an existing description (using the latest.json file as reference)
• should provide programmatic access to history.json + latest.json together to get a listing