Add no-DB unit tests using pengdows.crud.fakeDb, reaching ~93% Dapper.dll coverage

[alaricd]

….dll coverage

Introduces 775 pure unit tests that run without a live database connection,
using pengdows.crud.fakeDb v2.0.1 as a fake ADO.NET provider. Tests target

Coverage achieved:

• Dapper.dll overall: 86.1% (up from ~0% no-DB coverage)
• SqlMapper.cs: 82.3% (exceeds 80% goal)
• CommandDefinition.cs, UdtTypeHandler.cs, SqlDataRecordHandler.cs, SqlDataRecordListTVPParameter.cs: 100%

Key areas covered by new FakeDbTests.*.cs files:

• All Query/Execute/QueryMultiple sync and async overloads
• MultiMap (2–7 types), dynamic multimap, GridReader
• DynamicParameters, TypeHandlers, TypeMapping, DefaultTypeMap
• PassByPosition (?x? syntax), TryStringSplit (InListStringSplitCount), PadListExpansions, empty IN-list handling
• Format() all TypeCode branches, ReplaceLiterals, ReadChar/ReadNullableChar
• SanitizeParameterValue for all enum underlying types
• CommandDefinition.GetInit() IL generation (BindByName, FetchSize, etc.)
• StructuredHelper.ConfigureTVP/ConfigureUDT IL generation and cache
• WrappedReader, WrappedBasicReader, DisposedReader, DbString, ValueTuples
• Struct params, ctor-sort params, pipelined Execute, error paths

[alaricd]

@mgravell — build is now green. 775 pure unit tests, no live database required, using pengdows.crud.fakeDb as a fake ADO.NET provider. Test-only dependency, zero production code changes. Happy to address any feedback.

[mgravell]

this looks like a lot of useful work; there are currently merge conflicts - I can't resolve them without push access; can you either add external PR push access, or help me resolve them?

[alaricd]

I will fix them

[alaricd]

@mgravell all the merge conflicts are resolved.

[alaricd]

@mgravell

Small correction to my earlier “zero production changes” statement: the added coverage exposed one real Dapper bug.

PackListParameters was calling LookupDbType(...) for expanded list parameters and receiving the registered ITypeHandler, but then discarding it and assigning each value through SanitizeParameterValue(...) instead.

The fix preserves the handler and calls handler.SetValue(...) for each expanded list item. This makes custom type handlers behave consistently between scalar parameters and IN @ids-style collection parameters.

I traced this path back to the August 5, 2015 commit that originally added type-map support for collection parameters; that implementation already retrieved the handler without using it. So this appears to be an approximately 11-year-old latent bug, not a recent regression.

The only other production-source change is changing DefaultTypeMap.GetSettableFields from private to internal for testability; its behavior is unchanged.

The new regression test specifically verifies that ITypeHandler.SetValue is invoked for every expanded collection element.