perf(table): memoize dataToRender and $params to cut per-cycle render cost (#19537)

[asrita-pyda]

Closes #19537

Defining the issue

Table rendering latency regressed for large datasets (#19537). Profiling the change-detection hot
path surfaced two pieces of redundant work that run on every CD cycle, because both Table and
the per-row TableBody use ChangeDetectionStrategy.Default:

1. dataToRender() re-allocates the row array every cycle. The body binds
   [value]="dataToRender(scrollerOptions.rows)" — a method binding. With a paginator it returned a
   fresh .slice() on every cycle, which re-fired the TableBody.value setter (a forced layout
   reflow getOuterHeight() for frozen rows) and handed *ngFor a new collection reference to
   re-diff.
2. BaseComponent.$params is recomputed per element per cycle. cx()/sx()/ptm() (and the
   $pt/$style/$globalPT/$defaultPT getters) read $params, which walked the
   $parentInstance chain via _getHostInstance and allocated two objects on every call. For a
   row directive such as pSelectableRow ([class]="cx('selectableRow')") this ran once per row,
   per cycle.

Fix

• dataToRender() (table.ts) now memoizes its result, returning a referentially stable array
  until its inputs change. Cache key: resolved data reference, length, effective first, rows,
  lazy, paginator. Sort reassigns _value = [...] and filter reassigns filteredValue, so any
  data change flips the reference and invalidates the cache automatically. Non-array arguments
  bypass the cache, preserving the original behavior byte-for-byte.
• BaseComponent.$params (basecomponent.ts) is computed once per instance and cached. Its
  inputs ($parentInstance, $name, $hostName) are immutable after construction, and instance
  remains the live this, so style/PT functions still read live state. The cache field is declared
  before parent = this.$params.parent so ES2022 define-semantics field init does not reset a cache
  populated during construction.

No public API changes and no change-detection-strategy changes.

Tests

Added deterministic, referential-stability tests (no wall-clock benchmarks) to table.spec.ts:
dataToRender memoization (stable reference, no per-cycle allocation, correct re-slice on
first/rows change, sort/filter cache busting, non-array bypass) and $params memoization
(stable reference, instance === component).

Validated against the suites that most exercise PassThrough + the _getHostInstance parent-chain
walk:

Suite	Result
table.spec.ts (incl. 23 PassThrough)	73 passing
treetable.spec.ts	174 passing
stepper.spec.ts	58 passing
tabs.spec.ts	73 passing

All green; no functional regressions in sorting, filtering, pagination, selection, virtual scroll,
templates, or PassThrough.

🤖 Generated with Claude Code

[asrita-pyda]

This PR addresses #19537 — it resolves the Table rendering-latency regression described there. See the PR description for the profiling findings (per-cycle dataToRender re-allocation and per-row $params recomputation) and the memoization fix.

[asrita-pyda]

@mehmetcetin01140 @cagataycivici would you mind reviewing when you have a moment? This is a focused, API-compatible performance fix for the Table render regression in #19537 (memoizes dataToRender and BaseComponent.$params), with tests passing across table/treetable/stepper/tabs. Thanks!