Patch for an encoding bug in the derive_locale_encoding function

Hello!

I've found a bug while I was working with the driver. It seems that
when the drive gets the encoding from the local environment it takes
everything, for example:

LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8

then it clears until the first dot and uses the rest as encoding:

UTF-8;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8

and this gets an error in the following code because is not a right
encoding string:

https://github.com/postgres/postgres/blob/master/src/backend/utils/mb/encnames.c#L570

There are two problems there:

1. First, you get the error because of the encoding
2. It hangs the connection because Postgres uses ereport instead of
returning -1 so it gets stuck

At first, I thought it was an error in the ifdef clause of the
postgres function but it seems correct although I don't know how to
catch that kind of errors to avoid this kind of behavior in cases like
this

In this mail, I've attached a patch to solve the bug. Hope it helps :)