Add formula (calculated) columns specification

[Copilot]

The grid has no concept of a derived column value — formatter only changes rendering, and pre-computing into the data source cannot support end-user authoring. Per the instruction on the issue, this is a specification only: no library code is changed.

Adds specs/Formula-Columns-Specification.md, following the structure of the existing wiki specifications (Tree, Group By, Summaries, Column Pinning, Excel Style Filtering). The filename matches a wiki page slug so the content can be transferred verbatim.

Contents

• Expression language — EBNF grammar, precedence, reference/literal forms, coercion, result type inference, MVP function library, Excel-shaped error values (#DIV/0!, #VALUE!, #REF!, #NAME?, #NUM!, #CIRCULAR!).
• Value-resolution hook — a 14-row table enumerating every existing resolveNestedPath(record, columnFieldPath(field)) call site and the change each needs. This is the central design point: it is what makes sorting, filtering, grouping, merging, summaries, search, clipboard and export work without per-column strategy code.
• Architecture — engine in igniteui-angular/core (no Angular deps); editor in a new opt-in grids/formula-editor entry point reached via an injection token, so grids/core keeps no static import. Dependency graph, invalidation scopes, WeakMap memoization keyed by record identity + formula version, zoneless (NG0100) constraints.
• UI — editor dialog, toolbar action mirroring igx-grid-toolbar-advanced-filtering, autocomplete via IgxAutocompleteDirective, error presentation, keyboard/ARIA, 30 resource strings, theming per the query-builder layout.
• API — option/method/event tables for the column, grid, IgxFormulaEngine, editor and toolbar action, plus interfaces and the IColumnState additions.
• Test plan — ~180 automated cases across 18 groups, 14 manual scenarios.
• Decisions and risks — Q1–Q7 and R1–R7 from the issue answered with rationale.

Two findings from the source that shaped the design

IgxSorting.getFieldValue does not receive grid, unlike FilteringStrategy.getFieldValue. The spec documents threading it through via an arrow closure — bind() on an arrow function is a no-op, so custom ISortingStrategy implementations calling valueResolver.bind(this) keep working.

DefaultSortingStrategy.compareValues falls through to the JS relational operators, which return false in both directions for an object operand — an error value would compare equal to everything rather than sorting last. The spec calls for an explicit FormulaError guard ahead of the nullish checks, with a regression test.

Proposed surface

<igx-column header="Total"
            [formula]="'[Price] * [Quantity] * (1 - [Discount])'"
            dataType="currency">
</igx-column>

grid.addFormulaColumn({ header: 'Total', formula: '[Price] * [Quantity]', dataType: 'currency' });
grid.formulaEngine.validate('[Price] * [Qty]');
// { valid: false, errors: [{ code: 'UNKNOWN_COLUMN', token: 'Qty', position: 10, length: 3 }] }

Note on API style

Members are described in the decorator style, and formulaFn types its parameter as any. Both match the surrounding code rather than the newer signal conventions: grids/core has 1012 @Input() against 22 signal input()s (all signal usage is in chat/ and grids/lite/), the mirrored advanced-filtering dialog and toolbar action both use @Input(), the WC/Blazor code-gen keys off the decorator annotations, and formulaFn deliberately parallels formatter?: (value: any, rowData?: any) => any on a non-generic ColumnType. The spec states this explicitly and notes the translation if grids/core migrates later; the return type is tightened to a FormulaValue union.

Open for discussion: the file lands in a new top-level specs/ folder (there is no existing docs/) — happy to relocate or move it straight to the wiki.

• Fixes Formula columns for the data grids #17550