Depend on crc32c package

[jasagredo]

When cross-compiling to Windows ouroboros-consensus using Haskell.nix, we encountered the following error:

GHC runtime linker: fatal error: I found a duplicate definition for symbol
    _ZN6crc32c6ExtendEjPKhy
whilst processing object file
/nix/store/8qz5kdvkm4cwx3lp8va8qg7bcd37597a-crc32c-lib-crc32c-x86_64-w64-mingw32-0.2.2/lib/x86_64-windows-ghc-9.6.7/crc32c-0.2.2-64Ea6b7xkwZIBzf0wemhyo/HScrc32c-0.2.2-64Ea6b7xkwZIBzf0wemhyo.o

The symbol was previously defined in
/nix/store/1cxcd8cdfbj9mmzbxxdmi8n82imk39g8-digest-lib-digest-x86_64-w64-mingw32-0.0.2.1/lib/x86_64-windows-ghc-9.6.7/digest-0.0.2.1-2QlBcNaJoyYSlQnmZZr6h/HSdigest-0.0.2.1-2QlBcNaJoyYSlQnmZZr6h.o

This could be caused by:
  * Loading two different object files which export the same symbol
  * Specifying the same object file twice on the GHCi command line
  * An incorrect `package.conf' entry, causing some object to be loaded twice.

iserv-proxy-interpreter.exe: loadObj "/nix/store/8qz5kdvkm4cwx3lp8va8qg7bcd37597a-crc32c-lib-crc32c-x86_64-w64-mingw32-0.2.2/lib/x86_64-windows-ghc-9.6.7/crc32c-0.2.2-64Ea6b7xkwZIBzf0wemhyo/HScrc32c-0.2.2-64Ea6b7xkwZIBzf0wemhyo.o": failed

The veredict is that both crc32c and digest (on which we depend via different dependencies) compile C sources for libcrc32c, and they both expose the same symbols. In a normal Windows build this is not a problem, but it is a problem for the cross-compilation.

digest has a git submodule with Google's crc32c, and crc32c instead has a local vendored version of the source code.

A possible alternative would be to create a package that prepares the C sources for both crc32c and digest. In the same spirit as https://hackage.haskell.org/package/zlib-clib.

I'm opening this PR as a way to start the discussion on how to best solve this. Unfortunately digest exposed quite some cabal flags which do not exist in crc32c, so I don't really know how to best proceed.

[jasagredo]

NOTE: the PR should probably not be merged as-is. It requires some thought before it is ready. I just opened the PR to open the discussion.

[TeofilC]

This sounds reasonable to me. I think it would also make sense to eventually just deprecate our module and suggest users use that dedicated package