Make tab-completion tests more robust.

Depending on as-yet-incompletely-explained factors, readline/libedit
might choose to emit screen-control escape sequences as part of
repainting the display.  I'd tried to make the test patterns avoid
matching parts of the output that are likely to contain such, but
it seems that there's really no way around matching them explicitly
in some places, unless we want to just give up testing some behaviors
such as display of alternatives.

Per report from Peter Geoghegan.

Discussion: https://postgr.es/m/CAH2-WznPzfWHu8PQwv1Qjpf4wQVPaaWpoO5NunFz9zsYKB4uJA@mail.gmail.com

src/bin/psql/t/010_tab_completion.pl

@@ -38,6 +38,12 @@ $node->safe_psql('postgres',
 my $historyfile = "${TestLib::log_path}/010_psql_history.txt";
 $ENV{PSQL_HISTORY} = $historyfile;
 
+# Ensure that readline/libedit puts out xterm escapes, not something else.
+$ENV{TERM} = 'xterm';
+
+# regexp to match one xterm escape sequence (CSI style only, for now)
+my $escseq = "(\e\\[[0-9;]*[A-Za-z])";
+
 # fire up an interactive psql session
 my $in  = '';
 my $out = '';
@@ -101,8 +107,12 @@ check_completion(
 	"select \\* from my\a?tab",
 	"complete my<tab> to mytab when there are multiple choices");
 
-# some versions of readline/libedit require two tabs here, some only need one
-check_completion("\t\t", "mytab123 +mytab246",
+# some versions of readline/libedit require two tabs here, some only need one.
+# also, some might issue escape sequences to reposition the cursor, clear the
+# line, etc, instead of just printing some spaces.
+check_completion(
+	"\t\t",
+	"mytab$escseq*123( |$escseq)+mytab$escseq*246",
 	"offer multiple table choices");
 
 check_completion("2\t", "246 ",