fix(csharp/src/Client): stop blocking on async calls in the ADO.NET wrapper

[RagingKore]

Implements the fix described in #4715.

AdbcCommand overrode only ExecuteDbDataReader and AdbcDataReader only Read(), so both BCL async entry points fell back to the synchronous bodies. ReadNextRecordBatchAsync becomes genuinely async, AdbcDataReader gains a ReadAsync override and AdbcCommand an ExecuteDbDataReaderAsync override.

Three notes on decisions in the diff, rather than as comments in the source.

ReadAsync returns a cached task on the intra-batch path instead of being async. It runs once per row, not once per batch, so an async method would allocate a state machine on the 4095 advances out of every 4096 that complete synchronously. Measured at 0 B per row, identical to Read().

Blocking that legitimately remains, on the synchronous APIs, now uses AsTask(). A driver's stream is genuinely asynchronous, so reading .Result on the ValueTask it returns is unsupported. That applies to AdbcDataReader.Read and to the schema-loading loop in AdbcConnection, which had the same defect independently of this change.

ExecuteDbDataReaderAsync only checks its CancellationToken rather than passing it down, because AdbcStatement.ExecuteQueryAsync takes none. The initial query call stays uncancellable exactly as it is today; per-batch fetches become cancellable through ReadAsync.

All additive: no driver changes, no public contract change. Read(), GetSchema() and ExecuteDbDataReader are unchanged, and a driver overriding only ExecuteQuery still gets the base Task.Run implementation.

Tests are in Client/ClientTests.cs. ReadAsyncDoesNotDeadlockOnASynchronizationContext hangs against current main and passes here.

Closes #4715

[CurtHagenlocher]

Thanks!