also uses correct header for strncasecmp.

Original information by @zecke in OpenSmalltalk/opensmalltalk-vm#174
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
openssl: Fix compability with OpenSSL 1.1 as used by debian

Norbert reported that a build for Debian9 fails to open outgoing
TLS connections. In OpenSSL the semantic of BIO_write for zero
sized writes has been changed. Do not attempt to write if the
length is zero. Check for the length before calling BIO_write.

I have updated the outgoing connection code and updated the
incoming connection one as well (didn't manually test it though)
and left the decrypt routine as is.

The Pharo testcase:
./products/phcogspurlinuxht/pharo ~/Pharo-60520.image eval "ZnEasy
getPng: 'https://pharo.org/files/pharo.png'"

OpenSSL-issue: openssl/openssl#4782
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

When we dynamically link against OpenSSL, the bundles are not portable,
as CentOS and friends use other SO_NAMEs than Debian and friends. Also,
soft-fallback for later features such as host name verification is hard.

When we statically link, we might lack behind the OS, the binaries are
bigger, and the legal situation is less clear.

So we now support not linking at all but rather lookup all necessary
functions/symbols at runtime.

This can be disabled with SQSSL_OPENSSL_LINKED which effectively results
in the dynamically-linked behavior. (This is preferable for platform
builds, eg, debs and rpms)