Package libssl into Kerblam!

[MrHedmad]

This is a tentative patch to fix #42. The libssl1.1 requirement is honestly out of nowhere (the build system?) since the openssl crate should link with whatever version is available.
The possible fixes are:

• Compile on the host system (with cargo install --git ...)
  • Pros: always works;
  • Cons: You need cargo and you need to wait for kerblam! to compile.
• Link with the proper version of libssl in our build systems;
  • Pros: It it as it should be, no extra work needed;
  • Cons: I have no idea what is making rustc link to the wrong lib;
• Package the libssl and the code to fetch the certificates in the host system (which would normally be done by the locally present, dynamically linked libssl) into kerblam! itself.
  • Pros: Easy to do and (probably) fixes the issue. Might help with having kerblam! run inside random docker containers (with unknown libssl versions).
  • Cons: Makes the build time longer (~+20%) and the executable larger (~2x, to 11Mb), which is undesirable.

TODO

Before merging, tick all of these boxes:

• cargo check passes without errors or warnings.
• @all-contributors is made aware of this PR.

[MrHedmad]

So, as an update to this for posterity. The issue is that reqwest uses by default the feature flag default-tls, which pulls in the openssl crate which uses local libssl bindings.
If you disable this flag (the only default flag) with default-features = false and add another backend to tls protocols you can sidestep this entirely. This is what 0503139 does: it uses rustls-tls, a rust-native implementation, as suggested by the devs of cargo-dist.