Fix bugs in libpq's GSSAPI encryption support.

 Fix bugs in libpq's GSSAPI encryption support.
 
 The critical issue fixed here is that if a GSSAPI-encrypted connection
 is successfully made, pqsecure_open_gss() cleared conn->allow_ssl_try,
 as an admittedly-hacky way of preventing us from then trying to tunnel
 SSL encryption over the already-encrypted connection.  The problem
 with that is that if we abandon the GSSAPI connection because of a
 failure during authentication, we would not attempt SSL encryption
 in the next try with the same server.  This can lead to unexpected
 connection failure, or silently getting a non-encrypted connection
 where an encrypted one is expected.
 
 Fortunately, we'd only manage to make a GSSAPI-encrypted connection
 if both client and server hold valid tickets in the same Kerberos
 infrastructure, which is a relatively uncommon environment.
 Nonetheless this is a very nasty bug with potential security
 consequences.  To fix, don't reset the flag, instead adding a
 check for conn->gssenc being already true when deciding whether
 to try to initiate SSL.
 
 While here, fix some lesser issues in libpq's GSSAPI code:
 
 * Use the need_new_connection stanza when dropping an attempted
 GSSAPI connection, instead of partially duplicating that code.
 The consequences of this are pretty minor: AFAICS it could only
 lead to auth_req_received or password_needed remaining set when
 they shouldn't, which is not too harmful.
 
 * Fix pg_GSS_error() to not repeat the "mprefix" it's given multiple
 times, and to notice any failure return from gss_display_status().
 
 * Avoid gratuitous dependency on NI_MAXHOST in
 pg_GSS_load_servicename().
 
 Per report from Mikael Gustavsson.  Back-patch to v12 where
 this code was introduced.
 
 Discussion: https://postgr.es/m/e5b0b6ed05764324a2f3fe7acfc766d5@smhi.se