[ORCA] Support hash partitioning in ORCA

[zhangwenchao-123]

GPORCA previously rejected any query touching a hash-partitioned table and fell back to the Postgres planner. Enable GPORCA to plan such queries, with static partition pruning for equality predicates and dynamic (join-driven) partition elimination.

How:

• CTranslatorRelcacheToDXL: stop raising "hash partitioning" for a single-column, single-level hash partition key and let the strategy flow into GPORCA. Composite keys, partitioning by expression and multi-level partitioning still fall back to the planner.
• IMDRelation: add ErelpartitionHash ('h') to the partition-type enum.
• CExpressionPreprocessor: a hash leaf's qual is a satisfies_hash_partition() call with no btree-interval form, so PcnstrFromChildPartition now returns NULL instead of asserting. Add FHashPartitionPruned(): substitute the query's equality constants for the partition-key columns into that call and evaluate it with the constant-expression evaluator; a leaf whose call folds to false cannot hold a matching row and is pruned. This reuses PostgreSQL's exact hashing (seed, per-column proc, combine), so selection is identical.
• CConstExprEvaluatorDXL: allow folding any column-free immutable expression (e.g. satisfies_hash_partition over constants), not only (const cmp const). Volatile/stable and column-referencing expressions are still rejected.

Dynamic partition elimination needs no hash-specific code: once hash tables become CLogicalDynamicGet the existing CPhysicalPartitionSelector path is partition-type agnostic, and CPartPruneStepsBuilder resolves the strategy from the partition's own hash opfamily.

ORCA vs Postgres planner behavior:

• Partition selection and results are identical. For the supported single-column, single-level hash key, an equality predicate prunes to exactly the same surviving partition(s) as the Postgres planner and returns the same rows row-for-row. When a single partition survives, both narrow dispatch to that one segment (Gather Motion 1:1).
• Unchanged: composite keys, partitioning by expression and multi-level partitioning still fall back to the Postgres planner, and range/list pruning is unaffected.

Authored-by: Zhang Wenchao zhangwenchao@apache.org

Fixes #ISSUE_Number

What does this PR do?

Type of Change

• Bug fix (non-breaking change)
• New feature (non-breaking change)
• Breaking change (fix or feature with breaking changes)
• Documentation update

Breaking Changes

Test Plan

• Unit tests added/updated
• Integration tests added/updated
• Passed make installcheck
• Passed make -C src/test installcheck-cbdb-parallel

Impact

Performance:

User-facing changes:

Dependencies:

Checklist

• Followed contribution guide
• Added/updated documentation
• Reviewed code for security implications
• This PR contains AI-assisted code generation
• Requested review from cloudberry committers

Additional Context

CI Skip Instructions

---