Better process for reducing, reviewing, and locking down dependencies

[madeken]

I really like what you've done with this library, and would really like to use it to replace some hand-rolled crypto I wrote. My biggest concern however is how to verify the build.

If I am not mistaken, the current build process involves at least 1251 unique packages, any of which could potentially subvert the build.

However, fortunately the vast majority of those libraries have no purpose outside of development. I propose that the dependencies are split between those that are essential for reproducing a build, and those for developer convenience.

[bitjson]

Thanks for opening this issue @madeken! I'm closing #19 in favor of this issue, since you've described some of the concerns really well here.

I'm hoping to work out a process for really locking down dependencies for this project and make it easier to review dependency updates. I also really like the idea of isolating the "build" dependencies from other development related ones (e.g. testing infrastructure). Have you seen this in any other projects? Any recommendations for how we should go about implementing that here?