[krbdev.mit.edu #2917] thread-specific data memory leak when dynamically unloading libraries

[Ken Raeburn via RT]

When using the pthread support, with the patches from ticket 2916,
there's going to be a potential memory leak.  If the krb5 libraries
store any thread-specific data, and are then unloaded, the thread
support code will not call the registered destructor functions.

This isn't trivial: If a thread is exiting at the same time, the thread
support code *will* call the registered destructor functions for the
krb5 data stored for that thread, and then will free the data structure
we use to store those pointers.  We have to avoid calling the destructor
twice, and referencing the TSD structure after it's been freed.

It'd be easy to do with a global mutex, but it would be better to avoid
that if we can.  If we can't avoid it, find the minimum set of places
where we actually have to lock it; I think we can probably avoid it on
getspecific() calls, but setspecific() I'm less confident of.  (Think
about multiprocessor systems, cache coherency, cache lines larger than
pointers, etc.  Can one thread writing one pointer cause a write to a
neighboring memory location to be lost?)