mit-krb5 thread support -- fork safety

[Sam Hartman]

I know that I object to krb5_keyblock becoming invalid after fork.
It's not particularly opaque and by definition, there is enough
information in the keyblock for the crypto library to get it working
again even if it needs to destroy memoized state.



As a side note we really should work on caching key schedules in MIT
Kerberos.  I realize Sun has done this, but as discussed, they have
done so in a manner we cannot duplicate or accept.

--Sam