fix: map MatrixOne connection SQLSTATEs

[iamlinjunhong]

Problem

MatrixOne ODBC reports generic HY000 for two connection failures that have standard ODBC SQLSTATEs:

• nonexistent MatrixOne user: expected 28000 (invalid authorization specification);
• nonexistent database: expected 3D000 (invalid catalog name).

This makes pyodbc and other ODBC clients unable to reliably distinguish authentication/configuration failures from generic driver errors.

Tested with MatrixOne main commit c6b2ac9c1eaff0db867e845723a8ce1d2102928f, matrixone-odbc base bcc10fec25e5cbc7f1febb70f280c0d94bcac2c3, Windows 11 x64, and pyodbc 5.3.0.

Root cause

1. MatrixOne returns native error 20101 and text containing there is no user for an unknown username. The connection path did not pass server error text to translate_error, so the driver could not classify it.
2. MySQL/MatrixOne native error 1049 is ER_BAD_DB_ERROR, but the mapping only handled ER_NO_DB_ERROR (1046).

Fix

• Pass the connection error text into translate_error.
• Map the MatrixOne unknown-user diagnostic to 28000 without treating every MatrixOne 20101 internal error as authentication failure.
• Map ER_BAD_DB_ERROR to 3D000 alongside ER_NO_DB_ERROR.

Minimal reproduction

import pyodbc

base = (
    "DRIVER={MatrixOne ODBC 9.7 Unicode Driver};"
    "SERVER=127.0.0.1;PORT=16012;PWD=111"
)

pyodbc.connect(base + ";UID=no_such_user;DATABASE=system")
# Before: HY000. After: 28000.

pyodbc.connect(base + ";UID=dump;DATABASE=no_such_database")
# Before: HY000. After: 3D000.

Regression coverage

mo_odbc_deep now uses a shared connection-failure helper and asserts:

• unreachable endpoint -> 08001 (existing behavior remains covered);
• unknown user -> 28000;
• unknown database -> 3D000.

Before / after

before: unknown user HY000, unknown database HY000
after:  unknown user 28000, unknown database 3D000

Test scope

• Visual Studio 2022 x64 RelWithDebInfo build: Unicode driver, ANSI driver, and mo_odbc_deep all PASS compilation.
• Direct loading of the newly built Unicode DLL, bypassing system Driver Manager registration:
  • unknown user -> 28000: PASS
  • unknown database -> 3D000: PASS
• Existing timeout/cancel mappings on the same base were not changed.

No Power BI scenario or Power BI-owned driver registration was modified.