Use the upstream Bitmani vulndb data for matching

[wagoodman]

Bitnami is providing vulnerability matching data for their contianers, which have embedded SPDX documents outlining the contained components: https://github.com/bitnami/vulndb . This could be leveraged in order to improve matching in grype for those components.

This involves at least the following tasks:

• Write a new vunnel provider so that we can pull and prepare the data for grype-db. Part of this work is understanding if this data fits into an existing schema, or if we need to create a new one (I think a new one is needed at first glance). feat: add Bitnami as new provider vunnel#512
• Update grype-db to be able to transform and write entries to the DB. This depends on the schema written out by vunnel. feat: add support for OSV schema grype-db#217
• Ensure that syft to be able to pick up on SBOMs that are contained within the /opt/bitnami/* locations (I think this should already work, but have not verified). Support Bitnami embedded SBOMs syft#3065
• Update [grype] to be able to match with these new db records. This will take a little bit of thinking. I don't think we need to add a new Matcher object, but most likely enhance the generic search.* functions to look for bitnami specific material and additionally search those namespaces. This might mean that we need to update the namespace logic to determine whether to include the additional bitnami namespaces (haven't thought through this entirely yet).

[willmurphyscode]

For the last item, updating grype to be able to search by these new records, we're starting to think about that pretty early, because to write a correct namespace we need to know how grype should search.

@wagoodman do you think this is a good time to add a ByPURL search function, and emit the namespace bitnami:purl? If it's not time to add a new search type, which search type should these be added to?

The existing search.By* things are ByPackageLanguage, ByPackageDistro, and ByPackageCPE. Bitnami's data doesn't seem to fit well in any of those buckets, and I think searching by PURL directly is a capability we want anyway.