Resolve conflicts in src/backend/executor/nodeModifyTable.c

[RekGRpth]

1. Commit a04daa9 in src/backend/executor/nodeModifyTable.c changed the
   comment before the ExecInsert function, but earlier GPDB-specific
   commits had already added a GPDB-specific comment in the same location.

2. Commit a04daa9 in src/backend/executor/nodeModifyTable.c in the
   ExecDelete function deleted a couple of lines, but earlier
   GPDB-specific commits had already added a conditional error message
   before this location.

3. Commit c5b097f in src/backend/executor/nodeModifyTable.c moved some
   code to the new ExecCrossPartitionUpdate function in the ExecUpdate
   function. However, the earlier commit 19cd1cf had already added the
   segid and splitUpdate arguments to the ExecDelete and ExecInsert
   functions in these same locations.

4. Commit a04daa9 in src/backend/executor/nodeModifyTable.c removed the
   es_result_relation_info save in the ExecModifyTable function before
   calling the EvalPlanQualSetPlan function. However, earlier
   GPDB-specific commits had already added code before this location.

5. Commit a04daa9 in src/backend/executor/nodeModifyTable.c added a new
   resultRelInfo argument to the ExecModifyTable function when calling
   ExecInsert ExecDelete. However, the earlier commit 19cd1cf had already
   added the splitUpdate argument to the ExecInsert function.

6. Commit a04daa9 in src/backend/executor/nodeModifyTable.c added a new
   resultRelInfo argument to the ExecModifyTable function when calling
   ExecUpdate. However, earlier GPDB-specific commits had already added
   the code for split updates.

7. Commit a04daa9 in file src/backend/executor/nodeModifyTable.c in
   function ExecModifyTable when calling function ExecDelete added new
   argument resultRelInfo, while earlier commit 19cd1cf already added
   arguments segid and splitUpdate, and commit 973cf25 already added
   conditional call of function ExecPrepareTupleRouting before and
   conditional saving of resultRelInfo after this place.

[silent-observer]

Should we also remove a few GPDB-specific uses of it, while we're at it? There are a few mentions in copy.c, aocs_compaction.c and appendonly_compaction.c

[RekGRpth]

Should we also remove a few GPDB-specific uses of it, while we're at it? There are a few mentions in copy.c, aocs_compaction.c and appendonly_compaction.c

I think this should be done in a separate PR (when the compilation is fixing), as the current PR is already quite complex, and it's about resolving conflicts in a one specific file.