Feature-test macros for new-in-v17 libpq features

Back in commit 6991e774e we established a policy that, well,
I'll just quote the commit message:

Provide feature-test macros for libpq features added in v14.

We had a request to provide a way to test at compile time for the
availability of the new pipeline features. More generally, it
seems like a good idea to provide a way to test via #ifdef for
all new libpq API features. People have been using the version
from pg_config.h for that; but that's more likely to represent the
server version than the libpq version, in the increasingly-common
scenario where they're different. It's safer if libpq-fe.h itself
is the source of truth about what features it offers.

Hence, establish a policy that starting in v14 we'll add a suitable
feature-is-present macro to libpq-fe.h when we add new API there.
(There doesn't seem to be much point in applying this policy
retroactively, but it's not too late for v14.)

libpq has grown a bunch of new features in v17, and not one of
them adhered to this policy. That was complained of at [1],
so I looked into fixing it. After diff'ing v16 and v17 libpq-fe.h,
it looks like we need roughly this set of new feature-test macros:

LIBPQ_HAS_ASYNC_CANCEL PGcancelConn typedef and associated routines
LIBPQ_HAS_CHANGE_PASSWORD PQchangePassword
LIBPQ_HAS_CHUNK_MODE PQsetChunkedRowsMode, PGRES_TUPLES_CHUNK
LIBPQ_HAS_CLOSE_PREPARED PQclosePrepared, PQclosePortal, etc
LIBPQ_HAS_SEND_PIPELINE_SYNC PQsendPipelineSync
LIBPQ_HAS_SOCKET_POLL PQsocketPoll, PQgetCurrentTimeUSec

(Feel free to bikeshed on the names, but I think we don't want 'em
to get too much longer than these.)

Alternatively we could decide that people can use configure probes
to see if these functions are there, but I still think that there's
a good rationale for the feature-test-macro approach. It saves
people from re-inventing that wheel, it standardizes the way to
check these things (in particular, discouraging people from abusing
the server version number for this), and it provides some handy
documentation about what's new or not so new.

In connection with that last point, I wonder if we should include
commentary about when things came in. I'd originally thought of
just inserting the above names in alphabetical order, but now I
wonder if the patch ought to look more like

*/
+/* Features added in PostgreSQL v14: */
/* Indicates presence of PQenterPipelineMode and friends */
#define LIBPQ_HAS_PIPELINING 1
/* Indicates presence of PQsetTraceFlags; also new PQtrace output format */
#define LIBPQ_HAS_TRACE_FLAGS 1
+/* Features added in PostgreSQL v15: */
/* Indicates that PQsslAttribute(NULL, "library") is useful */
#define LIBPQ_HAS_SSL_LIBRARY_DETECTION 1
+/* Features added in PostgreSQL v17: */
+ ... as above ...

Thoughts?

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/CAFCRh-_Fz4HDKt_y%2Bqr-Gztrh%2BvMiJ4EFxFHDLgC6AePJpWOzQ%40mail.gmail.com