Defer KEYRING key creation until initialize

If we resolve a KEYRING cache and the key does not exist, wait until
initialize time to create it, to avoid wasting precious kernel memory
on a cache which might not ever be created.  Properly error out if
store_cred or start_seq_get is called on an uninitialized cache, as we
would for a FILE cache.

Adapted from a patch by simo@redhat.com.
Clarify variable names in cc_keyring.c

Consistently use "cache_name" and "cache_id" to talk about the name
and ID of the keyring containing the cache.  In krb5_krcc_resolve, use
"residual" for the residual string as we are no longer using it for
the cache keyring name, and use "anchor_id" for the keyring identified
by the prefix to make it clear that it is not the cache keyring.

Adapted from a patch by simo@redhat.com.
Improve collection test program

Add a test for iteration when the default cache name identifies a
subsidiary cache.  Free the context at the end so we can more easily
check for memory leaks.
Add collection support for KEYRING ccache type

Augment the KEYRING ccache type to support collection semantics
similar to those of the DIR type.  For keyrings with no anchor prefix,
maintain compatibility with old code by linking the initial primary
cache directly from the session keyring and naming it after the
collection.

See http://k5wiki.kerberos.org/wiki/Projects/Keyring_collection_cache
for more information.  Adapted from a patch by simo@redhat.com.
Support new KEYRING anchor names and big_key keys

Add support for the new anchor names persistent, user, and session.
The persistent anchor attempts to use a persistent keyring for a
specified uid, and falls back to the user keyring if it cannot; the
collection is stored at a fixed name within the persistent or user
keyring.  The session anchor uses the session keyring without legacy
semantics.

For all keyring types except legacy, attempt to use the "big_key" key
type on systems which have keyctl_get_persistent.  (They are
essentially unrelated features, but were added at the same time.)
This key type is stored in a kernel tmpfs and can store larger
tickets.

Since kernel commit 96b5c8fea6c0861621051290d705ec2e971963f1, new keys
created by add_key() only have VIEW permission for the user, and the
rest of the permissions require "possession," which means there is a
path from the thread, process, or session keyring to the key.  For the
user and persistent anchor types, we link the collection into the
process keyring to ensure that we have a possession rights on the
collection.

Adapted from a patch by simo@redhat.com.