Also improve object size handling in NativeUtil.

Also avoid memory allocation in newGSSOIDSet() renamed to makeGSSOIDset()
which now takes a singleton set argument and either assigns the requested
OID or with SPNEGO returns a static list of all the supported mechs. With
this we no longer need deleteGSSOIDSet().

We must not dispose() of any credential handle passed to the
NativeGSSContext() constructor.  But we must dispose() of credentials
that are acquired in NativeGSSContext.

This is very important because the JVM does not know about the size of
the JNI credential objects, so it doesn't readily recognize memory
pressure from them, leading to memory pressure issues in SASL and GSS
server applications.

There is only one token that we can extract an actual mechanism OID from
in the SPNEGO case when the native GSS library doesn't provide that
(though it should) in the API.  If the SPNEGO exchange ends up requiring
more than two tokens, then the previous code failed to establish a
security context.

Also, never raise if we cannot get an actual mech OID from SPNEGO
tokens.

Also use empty realm as wildcard for krbtgt names

This module is to be used for GSS applications in preference to
Krb5LoginModule, especially when using the native GSS provider.

Also don't force same name for acceptor and initiator.

Add commentary about native in Krb5LoginModule

We were reacquiring the initiator/acceptor credential upon security
context full establishment in order to indirectly perform a permission
check on the srcName/targName once we find out what they are.  But this
is just one more way to end up failing, which happens with Heimdal when
using SPNEGO because we ask to acquire a Kerberos credentials using a
SPNEGO MN and that fails.

Also, there was a security bug here: if the permission check fails then
we raise, but if the application already has a context handle, then it
can use it anyways if it catches the exception!  The fix for this is to
dispose() when the permission check fails.

Native objects are memory icebergs: they are much larger than the JVM
knows, so the GC might not dispose of them soon enough.