impl(bq_driver): add integration test for SQLSpecialColumns API

[Anshu6250]

Description

This PR establishes the integration testing baseline for the SQLSpecialColumns API against the existing driver, in preparation for its implementation in the new BQ driver.

Key Changes:

• Test Utilities: Added the Catalog::GetSpecialColumns helper to fetch and map special column metadata.
• Functional Parity: Added tests in catalog_test.cc to verify the existing driver's behavior for SQL_BEST_ROWID (with and without primary keys) and SQL_ROWVER.
  • Note: The existing driver acts as a stub here and always returns an empty result set, which these tests explicitly assert for parity.
• Metadata Validation: Added StatementTest.SQLSpecialColumns_VerifyMetadata to strictly ensure the returned schema matches the 8 standard columns defined by the ODBC 3.8 specification.

Note: All added tests are wrapped in #ifndef BQ_DRIVER_INTEGRATION_TESTS to ensure they exclusively run against the existing driver until the API is implemented in our new driver.

pipeline: link

[shivamd-gpartner]

why is it empty for every test case?

[shivamd-gpartner]

found out :

What the ODBC spec asks for

SQL_BEST_ROWID: "the optimal column or set of columns that, by retrieving values from the column or columns, allows any row in the specified table to be uniquely identified" — used by applications for positioned updates/deletes and re-fetching a row.
SQL_ROWVER: columns "automatically updated by the data source when any value in the row is updated by a transaction" (SQL Server rowversion, Oracle ORA_ROWSCN, etc.).
The spec explicitly allows an empty result set when the data source has no such columns; it does not require the driver to invent one.
Why BigQuery legitimately has none

There is no ROWID/OID pseudo-column and no auto-updated row-version column, so SQL_ROWVER has nothing to return.
Primary keys in BigQuery are NOT ENFORCED . BigQuery does not guarantee uniqueness, so PK columns do not satisfy "allows any row to be uniquely identified". Advertising them as BEST_ROWID would be misleading: an app that then does UPDATE … WHERE StringField=? AND IntField=? could hit multiple rows.
BigQuery has no positioned-update/scrollable-cursor model anyway, which is the main consumer of BEST_ROWID.
So Simba's choice — return a well-formed 8-column result set with zero rows, and SQL_SUCCESS even for a nonexistent table (same as its SQLPrimaryKeys behaviour) — is the conservative, defensible implementation. A driver for an RDBMS with enforced PKs would typically derive BEST_ROWID from the PK or a unique index; that reasoning simply doesn't transfer here which is the same for our driver