Get rid of osconfig.c

These variables were marked as internal in 1996.  Two are unused and
the other is easily replaced with the macro it is initialized from.
Get rid of krb5_{get,free}_krbhst

These functions were always internal.  They haven't been used since
v5passwdd was eliminated in krb5 1.4.
Move a bunch of stuff out of k5-int.h

Move internal declarations from k5-int.h to more localized headers
(like int-proto.h) where appropriate.  Rename many symbols whose
prototypes were moved to use the k5_ prefix instead of krb5int_.
Remove some unused declarations or move them to the single source file
they were needed in.  Remove krb5_creds_compare since it isn't used
any more.
make depend
Fix import_sec_context with interposers

The code was correctly selecting the mechanism to execute, but it was
improperly setting the mechanism type of the internal context when the
selected mechanism was that of an interposer and vice versa.

When an interposer is involved the internal context is that of the
interposer, so the mechanism type of the context needs to be the
interposer oid.  Conversely, when an interposer re-enters gssapi and
presents a token with a special oid, the mechanism called is the real
mechanism, and the context returned is a real mechanism context.  In
this case the mechanism type of the context needs to be that of the
real mechanism.

ticket: 7592
target_version: 1.11.2
tags: pullup
Replace "First introduced" with concise "New"
Export verto_set_flags from libverto

When the bundled libverto was updated from 0.2.2 to 0.2.5,
verto_set_flags should have been added to libverto.exports along with
the other new functions.

ticket: 7594 (new)
target_version: 1.11.2
tags: pullup
Fix a trivial file leak writing kadmind pid file

If we fail to write the pid to the pid file, we should still close the
file before returning from write_pid_file().  The consequences of this
bug are trivial because kadmin is just going to exit regardless.
Reported by Will Fiveash <will.fiveash@oracle.com>.
Fix minor KDC memory leaks

Fix some small memory leaks which happen only in rare failure
conditions.  Reported by Will Fiveash <will.fiveash@oracle.com>.