Add support for GTM to backup data at BARRIER command

This patch is a combination of series of patches that were checked in the
upstream XC code
Disable hot_standby for components setup by pgxc_ctl

XL does not support Hot Standby, but hot_standby is set to "on" while
initializing datanode/coordinator slaves using pgxc_ctl. Fix that so that Hot
Standby is disabled by default
Disable internal subtransactions.
Allow DMLs inside a plpgsql procedure on the coordinator.

We still block them on the datanodes, but its safe to execute them on a
coordinator.
Fix planner bug with nested PlaceHolderVars in 9.2 (only).

Commit 9e7e29c75ad441450f9b8287bd51c13521641e3b fixed some problems with
LATERAL references in PlaceHolderVars, one of which was that "createplan.c
wasn't handling nested PlaceHolderVars properly".  I failed to see that
this problem might occur in older versions as well; but it can, as
demonstrated in bug #10587 from Geoff Speicher.  In this case the nesting
occurs due to push-down of PlaceHolderVar expressions into a parameterized
path.  So, back-patch the relevant changes from 9e7e29c75ad4 into 9.2 where
parameterized paths were introduced.  (Perhaps I'm still being too myopic,
but I'm hesitant to change older branches without some evidence that the
case can occur there.)

Conflicts:
	src/backend/nodes/equalfuncs.c
Add missing gtm backup files to the repo

We missed them in commit f70597bb
When fetching from remote nodes, after obtaining initial
group of rows, send down to the node that it should start producing
the next batch so it is ready when we are ready to read them.

Patch submitted by Jason
Send down command ID to datanodes before sending a plan.

Plans are sent down to the datanodes in form of a string and datanodes
convert them back to a RemoteStmt structure using stringToNode() function. Plan
string have relation names which must be converted back to their local OIDs.
For that, datanodes lookup system catalogs. Now if a table is created and later
accessed in the same transaction, and if access requires secondary datanode
connections from oher datanodes, then SnapshotNow fails to find that table.
This happens because command ID is not sent down to the datanode prior to the
plan string. So datanodes use FirstCommandId to do the scan and fails to see
the tuple inserted by the same transaction, but through a diff session.

Fix this my sending down command ID prior to plan. Bug report by Aaron
Jackson and investigation/fix from me.