Fix postgres_fdw's issues with inconsistent interpretation of data values.
  For datatypes whose output formatting depends on one or more GUC settings,
 we have to worry about whether the other server will interpret the value
 the same way it was meant.  pg_dump has been aware of this hazard for a
 long time, but postgres_fdw needs to deal with it too.  To fix data
 retrieval from the remote server, set the necessary remote GUC settings at
 connection startup.  (We were already assuming that settings made then
 would persist throughout the remote session.)  To fix data transmission to
 the remote server, temporarily force the relevant GUCs to the right values
 when we're about to convert any data values to text for transmission. 
 This is all pretty grotty, and not very cheap either.  It's tempting to
 think of defining one uber-GUC that would override any settings that might
 render printed data values unportable.  But of course, older remote servers
 wouldn't know any such thing and would still need this logic. 
 While at it, revert commit 
f7951eef89be78c50ea2241f593d76dfefe176c9, since
 this provides a real fix.  (The timestamptz given in the error message
 returned from the "remote" server will now reliably be shown in UTC.)