Making the build process more robust

[raphaelrobert]

evercrypt-rust doesn't always successfully build on different systems. Recently I struggled to get it to work on both macOS and linux. This if what I found out:

• The issue on macOS was due to a regression in hacl itself: Testing of Chacha20Poly1305 doesn't work (missing some Evercrypt header) hacl-star/hacl-star#412. Given that regressions could occur again, it might make sense to pin a certain version of hacl.

• The tooling requirements on linux are not entirely clear. So far it seems what's needed is: make, some C compiler, some header files (probably for stdlib). It would be great to have the exact list and ideally have build.rs check for the presence of the tools.

[beurdouche]

If the build is failing from time to time, it likely means that we are missing something in our CI and we should add it.
It is also possible that what is used by evercrypt-sys is not the correct thing to use. Issue 412 is referring to a very specific internal way of testing. Normal testing is under CI so it doesn't fail.

[franziskuskiefer]

The hacl-star version in evercrypt-sys is fixed by the submodule version. So unless you update the git submodule you shouldn't have any issues.

There aren't a lot of dependencies for the hacl build. But I agree they could be better documented or even checked for at build time. My plan was to update the hacl build system to be more robust rather than doing a lot in the bindings. But we should probably do both.