Changes for how OpenSSL is loaded on *Nix platforms

Some changes have been made to the IdSSLOpenSSLHeaders unit in how OpenSSL lib files are dynamically loaded on *Nix platforms.

– Many *Nix systems have unversioned libcrypto/libssl symbolic links that point to specific OpenSSL versions. This way, as new OpenSSL versions are installed, the symlinks can be updated without app code needing to be updated to match. However, as OpenSSL continues to evolve, the symlinks on some systems now point to OpenSSL 1.1.0+, which Indy does not yet support (this is on the TODO list), so loading the symlinks is causing “Unable to load OpenSSL” errors at runtime on these systems. A new IdOpenSSLSetLoadSymLinksFirst() function has been added, which allows users to tell Indy whether to load the symlinks first before checking for specific OpenSSL versions, or vice versa. The default behavior is to load the symlinks first, to preserve existing functionality.

Update July 16 2019: a new IdOpenSSLSetCanLoadSymLinks() function has been added, which allows users to tell Indy whether to load the symlinks at all.

– On some *Nix systems, OpenSSL lib files have a letter attached to the version number in their filenames, ie “libcrypto.so.1.0.0a”, “libcrypto.so.1.0.0b”, “libcrypto.so.1.0.0c”, etc. Indy has been updated to look for these additional files when loading specific OpenSSL versions.