Fix NPE when using default initiator credentials

The JGSS interface allows calls to GSSManager.createContext with
default initiator credentials by passing null as the input
GSSCredentials argument. We were not correctly handling this case.
Introduce a Kerberos Login Module replacement

The Sun/Oracle JGSS implementation integrates with JAAS, allowing one
to store credentials in the Subject associated with a particular
access control context and to use those credentials. This provides
application developers with a simple way to multiplex different
identities into a Kerberized application. With respect to the MIT
Kerberos/GSSAPI implementation, this functionality depends on being
able to control the credentials cache used by the GSSAPI interfaces.
This functionality is notably lacking from the Sun "Native JGSS"
implementation (which allows use of platform-native GSSAPI libraries
on Solaris and Linux).

This patch adds a JAAS Login Module that authenticates using the
platform-native MIT Kerberos libraries and stores a handle to the
credentials cache in the access control Subject. A subsequent patch
will integrate with the JGSS implementation to use the stored
credentials.
Use existing credentials when available in Subject

When requesting credentials from the GSSManager, first check the
subject to see if matching KerberosCredentials exist; if so, import
from these instead of calling gss_acquire_creds and relying on the
default credentials cache.

This patch allows another entity (e.g. a LoginModule) to stash
credentials in a JAAS Subject for subsequent use in JGSS sessions.
Populate TGT KerberosTicket in subject

The Sun Krb5LoginModule stores that Ticket Granting Ticket for a
Kerberos-authenticated entity in the Subject. Our JGSS module doesn't
use the Subject as a credentials cache (except insofar as we stash a
handle to the underlying libkrb5 context and ccache), but existing
applications may depend on this functionality (e.g. to check directly
whether the TGT is expired before initiating GSSAPI credentials
acquisition). This patch populates a KerberosTicket structure with the
contents of the TGT and stashes them in the Subject at login time.
Add option to store keys in Subject

Application compatibility option for apps written against Sun's JGSS
implementation that expect to find server keys in the Subject's
private credentials set.
Request renewable ticket
Stash KerberosPrincipal in the Subject

More application compatibility
Check Subject when using default credentials

It is permissible to call GSSManager.createContext with null
credentials, in which case the default initiator credentials should be
used. This patch makes sure we look for credentials that are cached in
the Subject before passing down into the kerberos library.