Patch: Platform-independent SSPI authentication support

[A year has gone by since I last posted this message with no
response (maybe because it didn't show up on the list either), so
I'm trying again.]

The attached patch provides platform-independent support for the SSPI
authentication method (that is only supported by servers running on
Windows) in the JDBC driver. Please note that this patch supports SSPI
authentication by using the existing GSSAPI code, it does _not_
require the underlying system to know anything about SSPI.

I should also point out that GSSAPI support has been removed from the
PostgreSQL binary installers for Windows in version 9.0, so there is
currently no authentication method available in these builds that
supports passwordless authentication via the JDBC driver.

The patch applies against REL9_1_STABLE, as well as CVS trunk. I have
not tested it in a while, but last year, the resulting driver worked
on both Windows 7 and Windows XP SP3 clients in a domain with a
Windows 2008 DC, accessing PostgreSQL 8.4.4 and 9.0.2 on a Windows
2008 server, and there has been very little change in the affected
code. The equivalent change to libpq, which has been released in
9.1.2, worked in all environments I tested in. [1]

The patch does two things:

- It adds client-side SSPI support in the simplest possible way: by
acting as if it was the same as GSSAPI. This works because the
Negotiate SSP that is used by the server for SSPI authentication is
clever enough to also handle incoming GSSAPI tokens (without SPNEGO
encapsulation). This is the documented behavior of the Negotiate
SSP, it is not a compatilibity quirk.

- It improves on that by adding the OID for the SPNEGO mechanism to
the authenticator. This works only on Sun Java 1.6 and later;
SPNEGO support is not available in earlier releases. With this
change, the SPNEGO negotiation is actually performed on the wire.
In my environment, authentication succeeds even with
"sun.security.spnego.msinterop=false", if that even has any effect.

[1]
<http://archives.postgresql.org/message-id/4D3C42F3.4080503@chrullrich.net>