Parameterized search paths for default keytab, ccache

[ghudson@MIT.EDU]

An offshoot of the keytab initiation design is that we plan to augment
the default keytab and ccache to be search paths of parameterized
keytab or ccache names, and similarly make the default client keytab a
parameterized path.  The search path could be set at configure time by
the OS distributor, and possibly also from a krb5.conf relation (like
the existing default_keytab_name, or Heimdal's default_cc_name).  I'm
not actually sure what the intended use cases are for multiple search
path entries, but I can hypothesize:

* Support a per-user acceptor without having to set KRB5_KTNAME for
  each acceptor, but fall back to /etc/krb5.keytab if the user doesn't
  have one.

* Support per-session ccaches (using getsid() as the parameter, I
  guess?) without needing to set KRB5CCNAME for each session.

* Use a DIR ccache in /run/user, but fall back to /tmp/krb5cc_{uid} if
  the /run/user directory hasn't been set up.

The parameterization part seems pretty straightforward.  Heimdal has a
facility for this (expand_path.c) which we can probably adapt.

The search path part is a bit more subtle.  krb5_kt_default() and
krb5_cc_default() do not necessarily return a keytab or ccache which
already exists, because the caller may be intending to create and
write to the object (e.g. kadmin ktadd, or kinit).  So "return the
first one which exists" doesn't work.  Nico suggested that we use
container existence (which means parent directory existence for FILE,
directory existence for DIR, and is probably always true for
API/KEYRING).  Is that sufficient for the keytab use cases?