refactor: Integrate the materialized CTE into the plan and pipeline

[SkyFan2002]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

This PR improves the execution of materialized CTEs. Previously, a temporary table was created in the bind phase. This had several drawbacks:

1. the CTE and main query couldn't be jointly optimized by the optimizer
2. the information from "explain" and "profile" is inaccurate
3. automatic memory spilling of materialized CTE at the query level wasn't possible.

The proposed changes allow for better integration of materialized CTEs into the planning and optimization stages. Note that this PR does not implement distributed execution of materialized CTEs, which is planned to be improved in subsequent PRs

Example

explain with t1 as materialized (select number as a from numbers(10)), t2 as materialized (select a as b from t1) select t1.a from t1 join t2 on t1.a = t2.b;
----
MaterializedCTE: t1
├── TableScan
│   ├── table: default.system.numbers
│   ├── output columns: [number (#3)]
│   ├── read rows: 10
│   ├── read size: < 1 KiB
│   ├── partitions total: 1
│   ├── partitions scanned: 1
│   ├── push downs: [filters: [], limit: NONE]
│   └── estimated rows: 10.00
└── MaterializedCTE: t2
    ├── CTEConsumer
    │   ├── cte_name: t1
    │   └── cte_schema: [number (#2)]
    └── HashJoin
        ├── output columns: [numbers.number (#0)]
        ├── join type: INNER
        ├── build keys: [t2.b (#1)]
        ├── probe keys: [t1.a (#0)]
        ├── keys is null equal: [false]
        ├── filters: []
        ├── build join filters:
        │   └── filter id:0, build key:t2.b (#1), probe key:t1.a (#0), filter type:bloom,inlist,min_max
        ├── estimated rows: 0.00
        ├── CTEConsumer(Build)
        │   ├── cte_name: t2
        │   └── cte_schema: [number (#1)]
        └── CTEConsumer(Probe)
            ├── cte_name: t1
            └── cte_schema: [number (#0)]

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is