Add WithConstant factory methods for single constant Setter creation

[konard]

🤖 AI-Powered Solution

This pull request solves issue #7 by implementing static factory methods that allow creating Setter<TResult, TDecision> instances with a single constant value.

📋 Issue Reference

Fixes #7 - Think about setter with single constant, without True/False cases

🔧 Implementation Details

Problem

The issue identified that "in real life usage only one constant is actually used," but the current API required specifying both true and false values:

// Before: Required both true/false constants
var setter = new Setter<uint, uint>(constants.Continue, constants.Break, constants.Null);

Solution

Added two static factory methods to Setter<TResult, TDecision> class:

1. WithConstant(TDecision constantValue) - Creates a setter with the same constant for both true/false cases
2. WithConstant(TDecision constantValue, TResult defaultValue) - Same as above but with a specified default result value

Usage Examples

// Simple single constant usage (as requested in the issue)
var setter = Setter<uint, uint>.WithConstant(links.Constants.Break);

// With default value
var setterWithDefault = Setter<uint, uint>.WithConstant(42, 999);

// Both methods return the same constant value
Console.WriteLine(setter.SetAndReturnTrue(100));  // Returns: 42
Console.WriteLine(setter.SetAndReturnFalse(200)); // Returns: 42

✅ Changes Made

• Added static factory methods: WithConstant(constantValue) and WithConstant(constantValue, defaultValue)
• Comprehensive tests: Added WithConstantFactoryMethodTest and WithConstantAndDefaultValueFactoryMethodTest
• Demo implementation: Created experiments/SingleConstantSetterDemo.cs showing real-world usage
• Constructor disambiguation: Used static factory pattern to avoid ambiguity issues when TResult and TDecision are the same type

🧪 Testing

All tests pass (6/6):

• Existing functionality remains unchanged
• New factory methods work correctly with same constant for both true/false values
• Both variants (with and without default value) function as expected

📚 Design Rationale

Why static factory methods instead of constructors?

• Avoids constructor ambiguity when TResult and TDecision are the same type (e.g., Setter<uint, uint>)
• Provides clear, descriptive names that indicate the behavior
• Follows established patterns in the .NET ecosystem
• Maintains backward compatibility

The implementation addresses the core need expressed in the issue while maintaining clean, unambiguous API design.

---

🤖 Generated with Claude Code