Previously, `Explicit Redistribute Motion` was added if there were any motions
in the subplan, ignoring any motions in `InitPlans`.

This patch updates the logic: if an `Explicit Redistribute Motion` has no
motions underneath it's subtree, then the row to update must originate from the
same segment, and no `Explicit Redistribute Motion` is needed. If there are any
motions, `Explicit Redistribute Motion` should be added only if there is a
motion between the scan and the `ModifyTable` on the relation we are going to
update.

Even if previous Motions were performed on a leaf partition or inherited table,
targetlists from Motions refer to relids of their parents. So, if relid has a
superclass, we should check for inheritance instead of comparing Oids.

While checking the assumption that the right subtree is more frequent, I found
out that target list of `Redistribute Motion` may contain columns which are not
used for distribution. Behavior was correct only because the right subtree is
checked first. In cases when the scan would be in the left subtree, this is
incorrect, and `hashExprs` need to be checked instead.

Checking `hashExprs` may contain different structures that inherit `Expr` node.
The structure we need is of type `Var`, because it's the only child of `Expr`
node that we can get relation ID from.

…cit Motion

…st Explicit Motion"

This reverts commit 8cfe09c.
Explicit Redidistribute Motion is not requested unless IT IS
UPDATE/DELETE

…he same plan)

This reverts commit 955356e.

This reverts commit e5fbce1.

Explicit Redistribute Motion here is unnecessary.

…ons"

This reverts commit 99b32b3.

This reverts commit e7a5544.

…ExplicitMotion

This reverts commit bc89960.

Skip InitPlans, but don't restore a useless test.

This reverts commit bb559fd236bda017152005fa8eebfc0b58751695.