Protocol Version 2 Support Removal

Remove support for backend protocol version 2.
Optimize NpgsqlQuery for re-use.
Introduce a number of static NpgsqlQuery objects for often used internal commands.
Fix a bug where the connection state was throwing an exception after having been disposed.

http://msdn.microsoft.com/en-us/library/system.data.idbconnection.state(v=vs.100).aspx suggests that the state property should be readable even after disposing.
Add test to PR #164
Merge pull request #164 from Oipo/master

Connection state throws error incorrectly
Fixed NullReferenceException error if there's no record returned in ForwardsOnlyDataReader.UpdateOutputParameters
Added DataReaderTests.ExcuteReaderGettingEmptyResultSetWithOutputParameter to check if the reader works with empty result set when there's an output parameter
Check if there's any InputOutput or Output parameters before calling ParameterUpdateRow
Merge pull request #166 from tyler-nguyen/master

Fixed NullReferenceException error if there's no record returned in ForwardsOnlyDataReader.UpdateOutputParameters
Merge pull request #91 from DavidKarlas/master

Support for EFMigration and Database creation
Merge pull request #154 from npgsql/protocol_v2_tearout

Protocol Version 2 Support Removal
Move responsibility for null-terminating password up to auth methods

The NpgsqlPasswordPacket class assumes that it needs to null-terminate all
passwords that come through, but GSSAPI and SSPI send binary data. I move
the null-termination logic up to the state class, where it can decide
whether a password needs to be null-terminated.
Add GSSAPI support on Windows

For a Windows client to connect to a Linux-hosted PostgreSQL, it needs to
support GSSAPI. Fortunately, that just requires two changes:

* Use the hostname in the SPN
* Ask for the "kerberos" package instead of "negotiate"
Guess a case-specific username and optionally include realm for integrated auth

When PostgreSQL receives our username, it will expect the case to match
Active Directory. For us to guess it correctly requires an LDAP lookup.

While I'm here, I'm also adding an "IncludeRealm" option to the connection
string to add the realm to the username if the include_realm option is
being used on the server side.

One real nasty thing about having the username set upon reading the
property is that it freezes the username at possibly bad times, such as
when you're examining the connection builder in the debugger. I'd fix that
now, but I'm worried about breaking too much.

WARNING: There's a serious bug here where one user could get access to
another user's cached connection if connection pooling is on and integrated
security is being used. This is because the user ID is not in the
connection string until the connection is opened, which is after any
pooling logic. I'll address this in the next patch.
IMPORTANT: Freeze user name in connection string when using integrated security

When connection pooling is turned on, connections are cached by connection
string. But when integrated security is turned on, the user's identity
isn't part of the connection string, so two users can get each other's
connections back from the connection pool.

This patch forces the username to appear in the connection string if
integrated security is on, before any pooling takes place.
Fix PR #165.

NpgsqlConnectionStringBuilder was missing the Keyword ApplicationName in its valueDescriptions dictionary.
Thanks @pmuessig for the report and directions for the fix.
Merge pull request #170 from fluggo/gssapi-4

GSSAPI support on Windows, attempt 4 
Fix #165
Fix #162
GetResultSchema When current description is null
Cache UPNs by SID for three hours

This should solve the complaint of speed problems in #162.
Remove unused WindowsIdentityUserName property in connection string
Merge pull request #174 from Lundalogik/master

GetResultSchema When current description is null