Fix MultiMapAsync disposing the reader before unbuffered results are enumerated

[jinseojang0903]

Fixes #2099.

Problem

When calling any multi-map QueryAsync overload (e.g. QueryAsync<TFirst, TSecond, TReturn> or the Type[]-based QueryAsync<TReturn>)
with buffered: false, enumerating the returned sequence throws once the reader has already been disposed:

System.InvalidOperationException: Invalid attempt to call FieldCount when reader is closed.
at Dapper.SqlMapper.GetColumnHash(...)
at Dapper.SqlMapper.MultiMapImpl[...]+MoveNext()

Root cause

Both MultiMapAsync<TFirst,...,TSeventh,TReturn> and MultiMapAsync<TReturn> (Type[] overload) in SqlMapper.Async.cs wrapped the
DbDataReader in a using block. MultiMapImpl builds its result as a lazy, yield return-based IEnumerable<TReturn> that doesn't
start executing until the caller enumerates it. For buffered: false, the async method returns that un-enumerated sequence directly — so
the using disposes the reader immediately on return, before the caller ever gets a chance to read from it.

The single-type QueryAsync<T> path already avoids this by deferring disposal: it hands the reader into a small iterator
(ExecuteReaderSync) that only disposes it once the caller finishes enumerating. This PR applies the same pattern to both multi-map
overloads, adding a matching IEnumerable<TReturn>-based overload of ExecuteReaderSync for them to share.

Fix

• SqlMapper.Async.cs: transfer reader ownership into the deferred sequence instead of disposing it unconditionally when buffered: false.
• No change to the buffered: true path (already worked correctly, since .ToList() fully consumes the reader before the method returns).

Tests

Added two regression tests in AsyncTests.cs, following the existing TestMultiMapWithSplitAsync / TestMultiMapArbitraryWithSplitAsync
style:

• TestMultiMapWithSplitUnbufferedAsync
• TestMultiMapArbitraryWithSplitUnbufferedAsync

Both fail with the reported exception before this fix and pass after it. Full suite run locally (net8.0 + net10.0, SQL
Server/MySQL/Postgres) with no regressions.