[PATCH] Fix default partition validation for reordered child columns

Hi, Hackers.

I found a case where adding a partition succeeds even though a child of
its default partition contains a row that belongs to the new partition.
The row then becomes invisible to queries that prune the default
partition.

Here is a reproducer on current master:

CREATE TABLE defmap (a int, b int) PARTITION BY LIST (a);
CREATE TABLE defmap_def PARTITION OF defmap DEFAULT
PARTITION BY RANGE (b);
CREATE TABLE defmap_child (b int CHECK (b > 0), a int);
ALTER TABLE defmap_def ATTACH PARTITION defmap_child
FOR VALUES FROM (1) TO (100);
INSERT INTO defmap VALUES (0, 2);

CREATE TABLE defmap_0 PARTITION OF defmap FOR VALUES IN (0);
SELECT tableoid::regclass, a, b FROM defmap WHERE a = 0;
SELECT a, b FROM defmap_child WHERE a = 0;

Without the patch, CREATE TABLE succeeds. The query through defmap
returns no rows, while the direct query against defmap_child returns
(0, 2). The CREATE TABLE statement should instead fail because the
row already belongs to the proposed new partition.

check_default_partition_contents() maps the updated default constraint
to the child table's attribute numbers before scanning it. However,
its PartConstraintImpliedByRelConstraint() call receives the unmapped
constraint. With the reordered columns above, it compares the child's
CHECK (b > 0) against a condition intended for a, concludes that the
scan is unnecessary, and misses the conflicting row.

The attached patch uses the mapped constraint for both the implication
check and the scan, and adds this case to create_table's regression
tests. The child-side mapping was introduced in 23cccb17fe0 for the
scan, but was not used for the implication check.

I ran make -C src/test/regress check; all 239 tests passed.