Document the issue with threads and dlopen()

If using threads and OpenSSL is loaded via dlopen(), and subsequently
closed again via dlclose() *before* the threads are destroyed, then
OpenSSL will not free up the per thread resources. We need to document
this restriction, and provide some guidance on what to do about it.

I did some testing and discovered/verified a few of things (at least
this is the behaviour on Linux):

- Using OpenSSL via dlopen in a mutli-threaded app does leak memory if
threads are destroyed after dlcose() is called.
- In a single threaded environment, or if threads are destroyed prior to
dlclose() being called, then no memory is leaked
- Using the RTLD_NODELETE flag to dlopen solves the above problem
- Interestingly the OpenSSL atexit() handler gets called when dlclose()
is called rather than at application exit (I was worred that it might crash
if there was an atexit() handler for a function that has been unloaded)
- RTLD_NODELETE is a non-standard flag - but it does seem to be fairly
widely supported. As far as I could determine (via google), at least Linux,
Solaris, OpenBSD, FreeBSD, HP-UX all seem to support it.

I also tested on Windows (using LoadLibrary instead of dlopen and
FreeLibrary instead of dlclose) and experienced similar behaviour, except
that (AFAIK) there is no equivalent of RTLD_NODELETE on Windows.

GitHub Issue #653

Reviewed-by: Richard Levitte <levitte@openssl.org>