Add connect_timeout: a per-host deadline for multi-host connect

[lesnik512]

Fixes #1155. Related: #516, #1022, discussion #1071.

With several hosts, connect() runs all of them under one timeout. If the first host hangs instead of refusing, for example because a firewall drops its packets or the server accepts TCP and never answers, that one attempt uses up the whole timeout and the other hosts are never tried. The host loop in connect_utils._connect moves on only after OSError or _NextHostSignal, and a hang raises neither. With the reproducer from #1155 on 0.32.0, connect() fails with TimeoutError after 5.0s for timeout=5 and after 80.1s for timeout=80; the second host is never contacted.

This PR adds connect_timeout, which works like the libpq parameter of the same name: it "applies separately to each host name or IP address". psycopg 3's async connect does the same.

Why a separate parameter:

• As a limit on the whole call, timeout lets a hung first host use all of it. Turning timeout into a per-host limit would change the meaning of every existing call that passes it, including single-host ones. Splitting timeout evenly across hosts doesn't work either: a host that refuses at once leaves its share unused, and one slow but healthy host gets cut off early.
• Fix timeouterror on multihost config #1022 tried to fix this and was closed in favour of Use the timeout context manager in the connection path #1087. Use the timeout context manager in the connection path #1087 moved connect() to the timeout context manager but kept one deadline for all hosts, as @inikolaev pointed out there. In discussion Connect timeout with multiple host configuration #1071 they describe patching asyncpg locally for a zero-downtime upgrade, and downstream projects (for example modern-python/db-retry) wrap connect() to retry host by host.
• In FR: connect_timeout in Connection URIs #516 connect_timeout was declined as a libpq setting that asyncpg doesn't use. Since then asyncpg has taken on other libpq connection options with libpq's names, DSN keys and environment variables: target_session_attrs/PGTARGETSESSIONATTRS, service/PGSERVICEFILE, krbsrvname/PGKRBSRVNAME, gsslib/PGGSSLIB, sslnegotiation. Using the libpq name means a DSN that works with psql and psycopg also works here, instead of failing with UndefinedObjectError.
• It is opt-in. With connect_timeout unset, the behaviour is the same as today.

Behaviour:

• connect_timeout limits each address attempt: TCP connect, TLS, startup and authentication, and the target_session_attrs check. When it expires, the attempt is dropped, its TimeoutError becomes last_error, and the next address is tried, the same as for OSError. If every address times out, TimeoutError is raised.
• timeout keeps its meaning and its 60s default as the limit for the whole call, so the worst case is min(timeout, addresses * connect_timeout).
• The value is resolved the same way as target_session_attrs: keyword argument, then connect_timeout in the DSN, then the service file, then PGCONNECT_TIMEOUT. Zero or a negative value means no per-host limit, as in libpq. Non-numeric values raise ClientConfigurationError.
• connect_timeout in a DSN is no longer sent to the server as a setting. Today postgresql://...?connect_timeout=10 fails with UndefinedObjectError: unrecognized configuration parameter "connect_timeout" (FR: connect_timeout in Connection URIs #516).
• create_pool() passes connect kwargs through, so create_pool(..., connect_timeout=2) works without other changes.

Two smaller changes in _connect:

• With prefer-standby, the fallback used to be picked at random from every connection that had been opened. It now comes only from hosts that answered the attribute check. A host whose check timed out could otherwise still be returned.
• On Python 3.9 and 3.10, asyncio.TimeoutError is not a subclass of OSError, so it gets its own except clause. It re-raises when connect_timeout is unset, which keeps the old behaviour on those versions.

libpq takes whole seconds. Here the value can be fractional, like timeout.

Tests:

• TestConnectParams: DSN, keyword argument, environment variable and service file resolution, precedence, zero and negative values, invalid values.
• TestConnectTimeout: a local server that accepts connections and never replies, listed before the test cluster. With connect_timeout=0.5 the connection goes to the cluster in well under 5s. Without it, timeout=1 raises TimeoutError. With two silent hosts it raises TimeoutError after about 1s. A DSN with connect_timeout now connects. Two mock-based tests cover a hang during the target_session_attrs check and the prefer-standby fallback.
• Full suite passes on Python 3.13 (asyncio and uvloop for the new tests) and on Python 3.10 (the async_timeout path), against PostgreSQL 18. flake8 and mypy are clean.

I did not add a test where the TCP handshake itself hangs (a full listen backlog, or a blackholed address). Making that portable without root is fiddly, and the per-address deadline wraps the whole attempt, so the server that accepts and stays silent goes through the same code.