Enable SSL library detection via PQsslAttribute()

Currently, libpq client code must have a connection handle
before it can query the "library" SSL attribute.  This poses
problems if the client needs to know what SSL library is in
use before constructing a connection string.

Allow PQsslAttribute(NULL, "library") to return the library
in use -- currently, just "OpenSSL" or NULL. The new behavior
is announced with the LIBPQ_HAS_SSL_LIBRARY_DETECTION feature
macro, allowing clients to differentiate between a libpq that
was compiled without SSL support and a libpq that's just too
old to tell.

Author: Jacob Champion <pchampion@vmware.com>
Reviewed-by: Robert Haas <robertmhaas@gmail.com>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/4c8b76ef434a96627170a31c3acd33cbfd6e41f1.camel@vmware.com

doc/src/sgml/libpq.sgml

@@ -2581,6 +2581,16 @@ const char *PQsslAttribute(const PGconn *conn, const char *attribute_name);
          </varlistentry>
        </variablelist>
       </para>
+
+      <para>
+       As a special case, the <literal>library</literal> attribute may be
+       queried without an existing connection by passing NULL as the
+       <literal>conn</literal> argument. The historical behavior was to return
+       NULL for any attribute when a NULL <literal>conn</literal> was provided;
+       client programs needing to differentiate between the newer and older
+       implementations may check the
+       <literal>LIBPQ_HAS_SSL_LIBRARY_DETECTION</literal> feature macro.
+      </para>
      </listitem>
     </varlistentry>