Match a plain explode against an explode with ordinality

[g31pranjal]

An explode WITH ORDINALITY flows an anonymous (element, ordinal) struct. Until
now the value standing for that struct was a single opaque QueriedValue, which
made the element unreachable to MaxMatchMap: it descends into record
constructors, but an opaque value offers nothing to match against but itself. A
query that explodes a collection plainly therefore had no correspondence to a
candidate that explodes the same collection with ordinality, and any such match
was lost.

ExplodeExpression.explodeResultValue now builds the ordinality variant as a
RecordConstructorValue of two QueriedValues. The element stays the first
column deliberately: MaxMatchMap takes the first reachable candidate value that
compares equal, and a QueriedValue compares equal to any other, so an element
would just as happily match the ordinal if the ordinal came first. The record is
built nullable so its type stays the one explodeResultType already declares --
that type backs the protobuf descriptor the plan builds at run time.

Because a QueriedValue was equal to every other QueriedValue regardless of
type, the two columns of that record were indistinguishable, and pulling a value
up through the explode found both. QueriedValue.equalsWithoutChildren now also
compares the result type.

subsumedBy gains the case itself: a plain explode is subsumed by an explode with
ordinality over the same collection, since the candidate produces at least
everything the query may produce. exactlySubsumedBy cannot express it, as its
equalsWithoutChildren compares isWithOrdinality.

[github-actions]

📊 Metrics Diff Analysis Report

Summary

• New queries: 0
• Dropped queries: 0
• Plan changed + metrics changed: 0
• Plan unchanged + metrics changed: 0

ℹ️ About this analysis

This automated analysis compares query planner metrics between the base branch and this PR. It categorizes changes into:

• New queries: Queries added in this PR
• Dropped queries: Queries removed in this PR. These should be reviewed to ensure we are not losing coverage.
• Plan changed + metrics changed: The query plan has changed along with planner metrics.
• Metrics only changed: Same plan but different metrics

The last category in particular may indicate planner regressions that should be investigated.