Add CommandDefinition.SetCommandSetup for configuring commands after Dapper setup

[toreamun]

This PR adds a simple, non-invasive extension point to configure IDbCommand instances after Dapper has completed its own setup.

Motivation

Applications communicating with cloud services need to handle transient faults. Microsoft.Data.SqlClient provides built-in Configurable retry logic, but while retry logic can be configured at the connection level (for Open() etc.), command-level retry requires setting SqlCommand.RetryLogicProvider on each command.

The current version of Dapper doesn't provide a way to configure provider-specific command properties like RetryLogicProvider.

Solution

This PR adds a minimal API:

public static void SetCommandSetup(Action<IDbCommand>? setup)

The callback is invoked at the end of internal SetupCommand, after Dapper has configured the command.

Usage example

// Configure once at application startup
var retryProvider = SqlConfigurableRetryFactory.CreateExponentialRetryProvider(new SqlRetryLogicOption());

CommandDefinition.SetCommandSetup(cmd =>
{
    if (cmd is SqlCommand sqlCmd)
        sqlCmd.RetryLogicProvider = retryProvider;
});

// All subsequent Dapper calls will have retry logic configured
connection.Query<int>("SELECT 1");

Why this approach?

• Minimal API surface - Single static method, follows existing patterns like SqlMapper.SetTypeMap
• Non-invasive - No changes to CommandDefinition constructor or public properties
• Database-agnostic - Dapper remains provider-independent; the callback handles provider-specific logic
• Zero overhead when not used - Simple null check

Related issues

• Addresses use case in Support for SqlRetryLogic #1864 (Support for SqlRetryLogic)
• Related to Custom CreateCommand method. Resolves #2127 #2128 (alternative approach - custom command creation vs. post-setup configuration)