Decide on future of (go-)leopard

[leopard](https://github.com/catid/leopard/issues) is unmaintained and we did some (minor) modifications to the C++ code already.

There are several paths we could go with this library:

1. maintain and improve the C++ library and continue using it via cgo (like this repository does)
2. re-implement the algorithm in golang
3. re-implement the performance-critical parts in [assembly](https://golang.org/doc/asm) and package it directly with the go-code (e.g. like On the long run, we should consider to implement parts of leopard in assembly (seriously) and integrate it directly in go-code (like e.g. sha2 in golang's crypto lib: https://golang.org/src/crypto/sha256/)

I think 3. would be the cleanest and probably also the most performant solution (but it also is the most time-consuming). Some tools might help us generate the assembly from the c code, e.g. https://github.com/minio/c2goasm#a-simple-example but they require more investigation: we'd first need to clarify which functions from leopard e.g. using AVX2 intrinsic we'd really need and also if there are still up to date (@adlerjohn reported benchmarks seem slower on a bleeding-edge AMD machine 🤔 ), then we could generate assembly for those few functions and write the remaining code plain golang.

Start by reviewing the existing C++ code and cgo integration, then inspect the reported benchmarks and the functions using AVX2 intrinsics. Compare the three implementation paths, including c2goasm and the Go crypto/sha256 example. Done means documenting and selecting a future direction for the library.

Written by the indexing model from the issue text.