Band-aid new postgres_fdw test case to remove error text dependency.

Buildfarm member lorikeet is still failing the test from commit
32a9c0bd, but now it's down to the should-have-foreseen-it problem
that the error message isn't what the expected-output file expects.
Let's see if we can get stable results by printing just the SQLSTATE.
I believe we'll reliably see ERRCODE_CONNECTION_FAILURE, since
pgfdw_report_error() will report that for any libpq-originated error.

There may be a better way to do this, but I'd like to get the
buildfarm back to green before we discuss further improvements.

Discussion: https://postgr.es/m/E1kPc9v-0005L4-2l@gemulon.postgresql.org
Discussion: https://postgr.es/m/2621622.1602184554@sss.pgh.pa.us

contrib/postgres_fdw/expected/postgres_fdw.out

@@ -9025,13 +9025,13 @@ SELECT 1 FROM ft1 LIMIT 1;
 
 -- If the query detects the broken connection when starting new remote
 -- subtransaction, it doesn't reestablish new connection and should fail.
+-- The text of the error might vary across platforms, so don't show it.
 CALL terminate_backend_and_wait('fdw_retry_check');
 SAVEPOINT s;
+\set VERBOSITY sqlstate
 SELECT 1 FROM ft1 LIMIT 1;    -- should fail
-ERROR:  server closed the connection unexpectedly
-	This probably means the server terminated abnormally
-	before or while processing the request.
-CONTEXT:  remote SQL command: SAVEPOINT s2
+ERROR:  08006
+\set VERBOSITY default
 COMMIT;
 -- Clean up
 DROP PROCEDURE terminate_backend_and_wait(text);

contrib/postgres_fdw/sql/postgres_fdw.sql

@@ -2687,9 +2687,12 @@ SELECT 1 FROM ft1 LIMIT 1;
 
 -- If the query detects the broken connection when starting new remote
 -- subtransaction, it doesn't reestablish new connection and should fail.
+-- The text of the error might vary across platforms, so don't show it.
 CALL terminate_backend_and_wait('fdw_retry_check');
 SAVEPOINT s;
+\set VERBOSITY sqlstate
 SELECT 1 FROM ft1 LIMIT 1;    -- should fail
+\set VERBOSITY default
 COMMIT;
 
 -- Clean up