fix: do not retry on wrong password (28P01) with sslmode=allow/prefer

[Mauricio0129]

Fixes #1306

Problem

When connecting with sslmode=prefer (the default) or sslmode=allow to a
PostgreSQL server and providing wrong credentials, asyncpg surfaces a misleading
no pg_hba.conf entry ... no encryption error instead of a clear authentication
failure.

Root Cause

The retry logic in __connect_addr catches InvalidAuthorizationSpecificationError
(SQLSTATE 28000) and triggers an SSL retry for both sslmode=prefer and
sslmode=allow. However, wrong password failures raise InvalidPasswordError
(SQLSTATE 28P01), a subclass of InvalidAuthorizationSpecificationError. The retry
then connects with a different SSL state, which the server rejects with the misleading
pg_hba.conf error — hiding the real cause from the user.

Fix

Check if the caught exception is specifically InvalidPasswordError (28P01) before
deciding to retry. Wrong password errors are not SSL-related and retrying with
different SSL settings cannot fix them. Only pg_hba.conf rejections (28000) warrant
a retry.

[elprans]

Early re-raise would break valid sslmode=allow/prefer fallback. PostgreSQL can use different authentication methods for hostssl and hostnossl. libpq performs that retry for every startup ErrorResponse, including 28P01. I pushed an improved fix that remembers the original password error and reraises it after all fallbacks have been exhausted.