QueryExpr represents filters three different ways (Scan.predicates, Filter.pred, Aggregate.having) #195

Summary

QueryExpr currently has three separate places a filter predicate can live:

• Scan.predicates: Vec<Predicate> — row-level filters pushed all the way down to a base scan
• Filter.pred: Predicate — a standalone node for predicates a scan can't absorb (e.g. a post-aggregate column)
• Aggregate.having: Option<Predicate> — an optional post-aggregation filter predicate

(docs/pre-asap-ir.md, Scan/Filter/Aggregate sections)

Raised in PR #180 review:

• docs: re-doing documentation #180 (comment) — "In scan there is a predicates, while in filter there is another."
• docs: re-doing documentation #180 (comment) — "So Filter is Having?"

Open question

Worth discussing whether Scan.predicates and Aggregate.having should be removed in favor of a single Filter node wrapping the scan/aggregate, at least until there's a concrete need (e.g. predicate pushdown) that requires filters to live directly on those nodes.