feat: Add public IConditionEvaluator interface for standalone condition evaluation

[vaceslav]

Summary

• Add IConditionEvaluator interface in TriasDev.Templify.Conditionals namespace
• Add ConditionEvaluator implementation wrapping internal ConditionalEvaluator
• Support Dictionary, JSON string, and IEvaluationContext inputs
• Include sync and async methods (EvaluateAsync wraps sync for API compatibility)
• Add CreateContext methods for batch evaluation scenarios
• Add null parameter validation with ArgumentNullException
• Add 26 unit tests covering all methods and edge cases

Closes #24

Test plan

• All 716 existing tests pass
• 26 new tests for ConditionEvaluator pass
• Null parameter validation tested
• JSON and Dictionary inputs tested
• Context creation and batch evaluation tested

[Copilot]

Pull request overview

This PR adds a public API for standalone condition evaluation by exposing the internal condition evaluation engine through a new IConditionEvaluator interface and ConditionEvaluator implementation.

Key Changes:

• New public IConditionEvaluator interface with synchronous and asynchronous evaluation methods
• ConditionEvaluator class that wraps the internal ConditionalEvaluator
• Support for Dictionary, JSON string, and IEvaluationContext inputs with context creation for batch operations
• Comprehensive test suite with 26 unit tests covering all public methods and edge cases

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
TriasDev.Templify/Conditionals/IConditionEvaluator.cs	Defines the public interface for condition evaluation with multiple overloads supporting Dictionary, JSON, and context-based inputs
TriasDev.Templify/Conditionals/ConditionEvaluator.cs	Implements the interface by wrapping the internal ConditionalEvaluator with proper null validation and async method support
TriasDev.Templify.Tests/ConditionEvaluatorTests.cs	Provides comprehensive test coverage for all public methods, including null validation, JSON parsing, and batch evaluation scenarios

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] The async methods lack CancellationToken parameters, which is a best practice for async APIs. While the current implementation uses Task.FromResult (which completes synchronously), adding CancellationToken support would:

1. Follow .NET async/await best practices
2. Make the API future-proof if true async operations are added later
3. Allow callers to cancel long-running operations

Consider adding overloads with CancellationToken cancellationToken = default parameters to all EvaluateAsync methods. Example:

Task<bool> EvaluateAsync(string expression, Dictionary<string, object> data, CancellationToken cancellationToken = default);

The implementation can check cancellationToken.ThrowIfCancellationRequested() before calling the sync method.

[Copilot]

The EvaluateAsync methods lack explicit null parameter validation tests. While these methods delegate to the synchronous Evaluate methods which do validate parameters, it's a best practice to have explicit tests for each public API method to ensure they throw ArgumentNullException for null parameters.

Consider adding tests like:

[Fact]
public async Task EvaluateAsync_WithNullExpression_ThrowsArgumentNullException()
{
    var data = new Dictionary<string, object> { ["Key"] = "Value" };
    await Assert.ThrowsAsync<ArgumentNullException>(() => _evaluator.EvaluateAsync(null!, data));
}

Similar tests should be added for all three EvaluateAsync overloads with null parameters.