docs: propose workload-wide planning, summary sharing, and materialization

[zzylol]

Summary

Propose ASAPPlanner's planning stages, from language-specific frontends through logical and physical optimization to selection of one physical plan for the whole workload. The deployment supplies empirical cost and accuracy models and execution capabilities, then executes the selected plan.

Add docs/design_docs/proposals/planner-layering.md and link it from the proposals index.

Before this PR

The planning boundary needs an explicit contract for workload-wide candidates, summary sharing, materialization, and plan selection.

After this PR

• Frontends produce CandidateLogicalDAGs; logical optimization produces CandidateLogicalASAPDAGs; physical optimization produces CandidatePhysicalASAPDAGs; selection returns one PhysicalASAPDAG.
• Logical optimization generates local exact and summary alternatives, then applies ASAP-aware common-subexpression elimination across computations and windows.
• Physical optimization explores materialization, retention and operator implementations. Outputs may be maintained at ingestion time, retained at query time, or rebuilt without materialization.
• Selection evaluates complete workload candidates using deployment cost and accuracy models, rejects candidates that fail requirements or capabilities, and chooses the cheapest remaining plan.

Four worked examples cover candidate growth (3 local, 54 logical and 156 physical alternatives), UnivMon sharing across three computations, KLL sharing across windows, and ingestion/query-time materialization choices.

Scope and validation

Documentation-only proposal; no runtime or API changes. Deployment-input types, summary subtract/delete design, and physical parallelism, partitioning and resource management remain TODO.

The branch's file contents have been restored to commit 8c29c2e376800ad0823d4917e121eed3b60ed3ab and verified identical with git diff. No runtime tests run.

[zzylol]

Self-reflection: This PR raises the need for complete design documents explaining how strategies, query workloads, and ASAP primitives fit into the architecture.

1. Calling for design documentation explaining each replacement strategy in ASAPPlanner, how it works within this architecture, and an end-to-end example for each strategy, in Document every ASAPPlanner replacement strategy with architecture mapping and an end-to-end example #546.
2. Calling for design documentation explaining how to add a new query workload, with end-to-end examples showing how it can use existing strategies and when an extension is needed, in Document adding new query workloads and reusing existing strategies with end-to-end examples #547.
3. Calling for design documentation explaining how to add a new ASAP primitive, sketch algorithm, or other summary algorithm, in Design the extension contract for new ASAP primitives and sketch algorithms #548. The assumption is that the algorithm and its strategy are supplied by an algorithm developer, not invented by ASAPPlanner. The design should separate: (a) supported aggregation intents, including statistics and window/time behavior; (b) summary operations it can use in the logical ASAP DAG, or genuinely new operations it requires; (c) materialization capabilities and execution-timing constraints, including whether an ingestion-time-only restriction is real or query-time computation is merely expensive; and (d) physical operator implementations. Include a complete end-to-end extension example.

The schema, physical data, and summary-state contract is separately requested in #545, following the discussion on #535.

FYI @milindsrivastava1997 @Selvomega @vyassekar