refactor: Reuse FilteredValueToken and fix architectural layering

[rosomri]

Summary

This PR addresses the architectural concerns raised in harttle/liquidjs PR #863 review comments by:

1. Reusing the existing FilteredValueToken instead of creating a duplicate GroupedExpressionToken
2. Fixing the layering violation where tokens depended on templates (Filter instances)
3. Moving filter resolution from parse time to render time

Architectural Changes

1. Reuse FilteredValueToken instead of GroupedExpressionToken

Before:

readGroupOrRange(): { type: 'range', range: RangeToken } | { type: 'groupedExpression', groupedExpression: GroupedExpressionToken }

After:

readGroupOrRange(): FilteredValueToken | RangeToken

This eliminates code duplication and leverages the existing FilteredValueToken class that was already designed for this purpose.

2. Fix Layering Violation

Problem: FilteredValueToken had resolvedFilters?: Filter[], causing tokens to depend on the template layer (violation of tokens → render → templates hierarchy).

Solution:

• Removed resolvedFilters from FilteredValueToken
• Added liquid reference to Context for runtime filter resolution
• Build Filter instances at render time in evalFilteredValueToken()

Before:

export class FilteredValueToken extends Token {
  public resolvedFilters?: Filter[]  // ❌ Token depends on template layer
}

After:

export class FilteredValueToken extends Token {
  // Only has FilterToken[] - proper layering maintained ✅
}

3. Lazy Filter Resolution (Render Time)

Before: Filters were resolved at parse time via resolveGroupedExpressionFilters():

// In tag constructors
resolveGroupedExpressionFilters(this.collection, liquid)

After: Filters are resolved lazily at render time:

function * evalFilteredValueToken (token: FilteredValueToken, ctx: Context, lenient: boolean) {
  assert(ctx.liquid, 'FilteredValueToken evaluation requires liquid instance in context')
  let val = yield token.initial.evaluate(ctx, lenient)
  
  for (const filterToken of token.filters) {
    const filterImpl = ctx.liquid.filters[filterToken.name]
    const filter = new Filter(filterToken, filterImpl, ctx.liquid)
    val = yield filter.render(val, ctx)
  }
  
  return val
}

Changes by File

Core Architecture

• src/context/context.ts: Added liquid?: any reference to Context for runtime filter resolution
• src/liquid.ts: Pass liquid: this when creating Context instances
• src/tokens/filtered-value-token.ts: Removed resolvedFilters (layering fix)
• src/render/expression.ts: Build Filter instances at render time in evalFilteredValueToken()

Simplification

• src/parser/tokenizer.ts: Simplified readGroupOrRange() to return FilteredValueToken | RangeToken
• src/template/value.ts: Removed resolveGroupedExpressionFilters() function entirely
• src/tags/case.ts, for.ts, tablerow.ts: Removed explicit resolveGroupedExpressionFilters() calls

Cleanup

• src/tokens/grouped-expression-token.ts: Deleted (replaced by FilteredValueToken)
• src/parser/token-kind.ts: Marked GroupedExpression as deprecated
• src/util/type-guards.ts: Updated isGroupedExpressionToken() as deprecated alias

Test Results

✅ All 1537 tests pass

Test Suites: 86 passed, 86 total
Tests:       1537 passed, 1537 total

Benefits

1. Proper Layering: Tokens → Render → Templates (no backward dependencies)
2. Code Reuse: Eliminated duplicate GroupedExpressionToken class
3. Lazy Evaluation: Filters resolved at render time, not parse time
4. Simpler Code: Removed recursive resolveGroupedExpressionFilters() function
5. Backward Compatible: All existing tests pass

Question for Review

This implementation follows @jg-rp's suggestion to add liquid to Context. The alternative mentioned in the PR comments was to pass Liquid to the Tokenizer constructor, but that would require changes to filter runtime tokenization support.

Does the approach of adding liquid to Context align with your architectural vision? Or would you prefer the Tokenizer constructor approach?

Related to harttle#863