Fix direct dispatch behavior with ShareInputScan

When direct dispatch optimization is enabled for shared CTEs (resulting in
ShareInputScan plan nodes), a deadlock could occur because of mismatch between
the segments on producer and consumer. This was happening because direct
dispatch list wasn't copied to the consumer when CTE was planned. However, the
issue is deeper than just that: it is possible that ShareInputScans executing
on different slices actually need different direct dispatch segments because
of other parts of the query executing on those slices. For example, if CTE is
UNIONed with another simple query that can be directly dispatched, it can
affect the direct dispatch list of that slice. However, since direct dispatch
lists should match for ShareInputScans, the direct dispatch lists should
actually be combined to preserve the correct behaviour. This issue is only
present for the Postgres optimizer, since ORCA doesn't seem to have any
optimizations equivalent to direct dispatch.

This patch adds a new fix to the apply_shareinput_xslice. During the first
pass we collect the merged direct dispatch info from all SharedInputScan's
invocations, and then during the second pass we replace their direct dispatch
info with the merged one. If the SharedInputScan wasn't actually shared or if
it wasn't cross-slice, this is a no-op since only one direct dispatch info is
present, so merging doesn't change anything.