[comphead]

Which issue does this PR close?

• Closes Memoize LAST_VALUE and NTH_VALUE with IGNORE NULLS so BoundedWindowAggExec can prune its buffer #26537.
• Closes NTH_VALUE(expr, -n) IGNORE NULLS is quadratic in the partition size #26538.
• Closes LAST_VALUE and NTH_VALUE with IGNORE NULLS keep the whole partition buffered #26539.
• Closes FIRST_VALUE, LAST_VALUE and NTH_VALUE build a ScalarValue for every row #26540.

Rationale for this change

With IGNORE NULLS, LAST_VALUE and NTH_VALUE over a frame that starts at the partition's first row kept the whole partition buffered and rescanned long NULL runs for every row. #26533 already fixed the common case of #26538. FIRST_VALUE, LAST_VALUE and NTH_VALUE also built a ScalarValue per row, which is slow for nested types.

What changes are included in this PR?

• memoize moves the frame start under IGNORE NULLS too. LAST_VALUE keeps its last non-NULL value and drops the whole frame.
• A new PartitionEvaluator::evaluate_ranges evaluates all frames of a batch at once, and NthValueEvaluator implements it with one take. Unlike the row index that FIRST_VALUE, LAST_VALUE and NTH_VALUE build a ScalarValue for every row #26540 suggests, this also covers a final FIRST_VALUE result whose row is already pruned.

NTH_VALUE(expr, ±n) with n > 1 still keeps the rows from the first valid row it needs.

What is the testing strategy for this PR?

New window.slt cases and a memoize unit test. In datafusion-cli with the release-nonlto profile:

Query	main	This PR
last_value(v) IGNORE NULLS, one 10M-row partition	5.64 s, 299 MiB	0.67 s, 43 MiB
last_value(v) IGNORE NULLS, 1M rows with one non-NULL value	3.79 s	0.13 s
last_value(st) over a struct, 64-row partitions	0.25 s	0.10 s

The built-in function cases of window_query_sql are 9% to 73% faster, except one-row partitions (u64_wide), which are unchanged.

Are there any user-facing changes?

PartitionEvaluator gains evaluate_ranges, with a default implementation.