Fix false cache hit accounting on initial MultiMapAsync execution

[Nacl-HCl]

Description

Fixes #2240

When executing an asynchronous multi-map query (\MultiMapAsync), Dapper calls \GetCacheInfo(identity, param, command.AddToCache)\ to resolve the parameter reader and set up the command. It then delegated to \MultiMapImpl, which performed a second call to \GetCacheInfo\ for the same identity without passing the already-resolved \CacheInfo.

Because \GetCacheInfo\ invokes \RecordHit()\ upon finding an existing cache entry (\TryGetQueryCache), this second internal lookup caused the very first execution of an async multi-map query to record a hit count of 1 rather than 0.

As reported in #2240, because \CollectCacheGarbage\ collects entries with \hitCount <= 0, queries executed once via \MultiMapAsync\ survived cache garbage collection, which could accumulate one-off/interpolated multi-map queries over time.

Changes

• Added optional \CacheInfo? cacheInfo = null\ parameter to both the generic and non-generic overloads of \MultiMapImpl.
• In \MultiMapAsync, passed the resolved \info\ and \CommandDefinition.ForCallback(command.Parameters, command.Flags)\ into \MultiMapImpl.
• In \MultiMapImpl, used \cacheInfo ?? GetCacheInfo(...).
• Added unit tests in \SqliteTests.cs\ verifying that initial execution of both generic and types-based \MultiMapAsync\ queries yields a hit count of 0, and that subsequent executions correctly record reuse (hit count = 1).

Verification

• Build completed with 0 errors across all target frameworks (
  et8.0,
  et10.0,
  etstandard2.0,
  et461, etc.).
• Unit test \Issue2240_MultiMapAsync_CacheHitAccounting\ verified on both
  et8.0\ and
  et10.0.
• All \SqliteTests\ passed with 0 failures.