Options Pattern Inconsistency: Standardize command option design

[thomhurst]

Problem

Command options across tool integrations follow inconsistent patterns:

• Naming Inconsistency: Some use 'DotNetBuildOptions', others 'DockerRunOptions'
• Pattern Variation: Different ways to configure each command
• Missing Builder Pattern: Some options lack fluent builders
• Validation Inconsistency: Some validate at registration, others at execution
• Documentation Gaps: Options not consistently documented
• Hard to Discover: No standard way to understand all available options

Current Design

// DotNet options with one pattern
public class DotNetBuildOptions
{
    public string? Configuration { get; set; }
    public string? Framework { get; set; }
}

// Docker options with potentially different pattern
public class DockerRunOptions
{
    public string? Image { get; set; }
    // ... different structure
}

var result = await context.DotNet().BuildAsync(new DotNetBuildOptions { ... });

Proposed Solution

Standardized options with fluent API:

public abstract class CommandOptions
{
    // Standard properties every command option should have
    public TimeSpan? Timeout { get; set; }
    public IEnumerable<string>? EnvironmentVariables { get; set; }
}

public class DotNetBuildOptions : CommandOptions
{
    public string? Configuration { get; set; }
    public string? Framework { get; set; }
    
    public static DotNetBuildOptions Default => new();
}

// Fluent API builder for all options
var result = await context.DotNet()
    .BuildAsync()
    .WithConfiguration("Release")
    .WithFramework("net8.0")
    .WithTimeout(TimeSpan.FromMinutes(5))
    .ExecuteAsync();

Benefits

• Consistent pattern across all tools
• Discoverability via fluent API
• Easier to add new options
• Standard validation across tools
• Better documentation opportunities
• Chainable method calls

Priority: MEDIUM - Breaking change, improves developer experience