TGS request interfaces

[ghudson@MIT.EDU]

Right now we have the following nested interfaces for the TGS path:

  krb5_get_credentials
    - The only public TGS API currently (except for validate/renew)
    - Performs the initial cache check for the target creds
    - Has its own flags number space (KRB5_GC_*)
    - Caches the resulting creds and intermediate TGTs
    - Has a flag to fetch only cached credentials
    - Has a flag to disable caching of the resulting cred (but not to
      disable caching of intermediate TGTs)

  krb5_get_creds_from_kdc (gc_frm_kdc.c)
    - Handles cross-realm TGT acquisition and referrals
    - Accepts flags in the KDC options namespace (KDC_OPT_*)

  krb5_get_cred_via_tkt (gc_via_tkt.c)
    - Handles decoding/validating a TGS reply and extracting new creds
    - Adds a few consistency checks around krb5int_make_tgs_request_ext

  krb5int_make_tgs_request_ext (send_tgs.c)
    - Purely about constructing TGS requests

We're about to add a new, asynchronous, public interface to this mix,
analagous to krb5_init_creds_{init,step}.  Luke's work initially made
this interface analagous to krb5_get_creds_from_kdc(), but I'm
wondering if it should be pushed up to the krb5_get_credentials()
level.  Relative to the code I currently have on the branch, that
would mean:

  * krb5_tkt_creds_init() would take KRB5_GC_* flags instead of
    KDC_OPT_* flags.

  * On the first call, krb5_tkt_creds_step() would perform the initial
    cache check for the target creds (meaning it would sometimes
    return from the first call with no request to make).

  * On receiving the final reply, krb5_tkt_creds_step() would cache
    the resulting target creds unless initialized with
    KRB5_GC_NO_STORE.

Currently the code replaces gc_frm_kdc.c; with this change it would
probably live in get_credentials.c and gc_frm_kdc.c would go away.

Opinions?