[r-jais]

Cold-starting SQL warehouses answer OpenSession with transient 503s, and the per-request retry budget (RetryMax) runs out before the warehouse is up. Clients such as dbt need a way to wait longer for the session.

Adds WithConnectTimeout(d). On the Thrift backend, OpenSession is bounded by d and retried with exponential backoff (RetryWaitMin/RetryWaitMax) while the error is a retryable one; other errors (bad token, missing warehouse) fail fast. Default 0 keeps a single attempt, so behaviour is unchanged unless set. Ported from our fork (dbt-labs#9) onto the internal/backend/thrift layout.

Only 429 and 503 are treated as retryable by the existing RetryPolicy (they surface as RetryableError), so 502/504 and network drops still fail fast after the per-request retries. This matches the fork, which uses the same RetryableError check; nothing wider was dropped in the port. The option is Thrift only: NewConnector rejects it together with WithUseKernel(true), because the kernel backend has no connect-timeout equivalent. On deadline the error wraps both the last retryable error and context.DeadlineExceeded. Documented in doc.go.

Independent of the polling PR from the same fork (it edits backend.go, backend_test.go and CHANGELOG.md in other places, so whichever merges second needs a trivial rebase). The foundry driver's connection timeout option (adbc-drivers/databricks) will use this once it is released.

Part of dbt-labs/dbt#16697