Fix instability in regression test for Parallel Hash Full Join

As reported by buildfarm member conchuela, one of the regression tests
added by 558c9d7 is having some ordering issues.  This commit adds an
ORDER BY clause to make the output more stable for the problematic
query.

Fix suggested by Tom Lane.  The plan of the query updated still uses a
parallel hash full join.

Author: Melanie Plageman
Discussion: https://postgr.es/m/623596.1684541098@sss.pgh.pa.us

src/test/regress/expected/join_hash.out

@@ -971,7 +971,8 @@ INSERT INTO hjtest_matchbits_t2 VALUES (2);
 -- Update should create a HOT tuple. If this status bit isn't cleared, we won't
 -- correctly emit the NULL-extended unmatching tuple in full hash join.
 UPDATE hjtest_matchbits_t2 set id = 2;
-SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id;
+SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id
+  ORDER BY t1.id;
  id | id 
 ----+----
   1 |   

src/test/regress/sql/join_hash.sql

@@ -523,7 +523,8 @@ INSERT INTO hjtest_matchbits_t2 VALUES (2);
 -- Update should create a HOT tuple. If this status bit isn't cleared, we won't
 -- correctly emit the NULL-extended unmatching tuple in full hash join.
 UPDATE hjtest_matchbits_t2 set id = 2;
-SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id;
+SELECT * FROM hjtest_matchbits_t1 t1 FULL JOIN hjtest_matchbits_t2 t2 ON t1.id = t2.id
+  ORDER BY t1.id;
 -- Test serial full hash join.
 -- Resetting parallel_setup_cost should force a serial plan.
 -- Just to be safe, however, set enable_parallel_hash to off, as parallel full