The 1.7.x fix released the GIL around SQLDriverConnect, SQLSetConnectAttr,
SQLEndTran and SQLDisconnect, which fixed the plain-connect deadlock through
in-process Python TCP forwarders (paramiko + sshtunnel). However, when a
parametrized SELECT leaves an open server-side cursor, the connection
teardown cascade still blocks: SqlHandle::free() calls SQLFreeHandle on the
STMT handle, which sends a SQL_CLOSE-equivalent network packet to the
server. With the GIL held, the forwarder thread cannot run sock.sendall
and the call deadlocks forever.

This change releases the GIL around the three remaining teardown calls
that may perform network I/O:

  * SqlHandle::free()           -> SQLFreeHandle(STMT/DBC)
  * SqlHandle::close_cursor()   -> SQLFreeStmt(SQL_CLOSE)
  * SQLFreeHandle_wrap()        -> SQLFreeHandle

Each release is gated on PyGILState_Check() AND !is_python_finalizing(),
because these paths can also be reached from interpreter-shutdown cleanup
where gil_scoped_release would crash with
  Fatal Python error: PyEval_SaveThread: ... the GIL is released

Adds a second regression test
(test_param_query_close_through_python_tcp_forwarder_does_not_deadlock)
that reproduces the latest @jschuba scenario via an in-process TCP
forwarder + parametrized SELECTs + conn.close() under a hard watchdog.
Verified the new test hangs (watchdog fires at 30s) without the C++
change and passes (completes in <0.5s) with it.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Audit follow-up to the previous teardown fix. Identified one additional
ODBC call site that performs a server round-trip while holding the GIL,
which deadlocks when the connection is routed through an in-process
Python TCP forwarder (the same #565-family pattern).

Fixed call site:

  * BindParameters() -> SQLDescribeParam
      Issued by the driver as sp_describe_undeclared_parameters when a
      parameter has SQL_UNKNOWN_TYPE - hit on every parametrized query
      that includes a None value.

Earlier drafts of this commit also wrapped Connection::isAlive(),
Connection::getInfo() and Connection::getAutocommit(), but those were
removed after empirical verification: SQL_ATTR_CONNECTION_DEAD and
SQL_ATTR_AUTOCOMMIT GETs are driver-cached client-side state per the
ODBC spec (MSDN explicitly states SQL_ATTR_CONNECTION_DEAD 'does not
query the data source for activity'), and SQLGetInfo for the standard
info types (SQL_DBMS_NAME, SQL_DATABASE_NAME, ...) returns data the
driver cached at login time. None of these are network calls.

Reached only from a Python-callable wrapper with the GIL held, so a
plain py::gil_scoped_release is sufficient (no is_python_finalizing
guard needed - that's only required for the destructor cascade fixed
in the prior commit).

Adds test_param_describe_through_python_tcp_forwarder_does_not_deadlock
which runs a parametrized SELECT with a None argument through the
in-process Python TCP forwarder under a 30s watchdog. Verified: the
test hangs (watchdog fires at 30s) without the SQLDescribeParam GIL
release and passes (<1s) with it. Full pytest suite: 1767 passed,
0 failed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…-gil-release-teardown

# Conflicts:
#	mssql_python/pybind/ddbc_bindings.cpp