Tracking cbits in the hackage ecosystem

Following https://github.com/haskell/security-advisories/pull/157 I think it's clear that bundled c sources are an issue.

I've been advocating against it for a long time, but there are cases where the alternative is basically leaving the end user alone with compiling a system library from source. Further discussion happened here https://discourse.haskell.org/t/haskell-cryptography-group-botan-the-first-milestone/9018/11

I think the least worst option is to create packages like `bzip2-clib` that do nothing but install headers and allow linking against the upstream code with no Haskell pieces whatsoever. These can be more easily tracked and shared maintenance is not an issue.

What should the sec team do here? I think there are three potential missions:

- publish recommendations for package maintainers (including the cbits topic)
- create tools to track such pure cbits packages against upstream versions (which is easy, since the cbits version is corresponding to the upstream versions)
- have a list of packages that bundle cbits in non-pure ways (here it's hard to figure out if code is outdated or vulnerable)

Start by reading security-advisories/pull/157 and the linked Discourse discussion about Haskell cryptography, Botan, and the first milestone. Compare the three missions listed in the issue—maintainer recommendations, tracking tools, and a list of non-pure bundled cbits—and define a concrete scope and acceptance criteria before implementation.

Written by the indexing model from the issue text.