QE processes largely don't care about client_encoding, because query
results are sent through the interconnect, except for a few internal
commands, and the query text is presumed to already be in the database
encoding, in QD->QE messages.

But there were a couple of cases where it mattered. Error messages
generated in QEs were being converted to client_encoding, but QD assumed
that they were in server encoding.

Now that the QEs don't know the user's client_encoding, COPY TO needs
changes. In COPY TO, the QEs are responsible for forming the rows in the
final cilent_encoding, so the QD now needs to explicitly use the COPY's
ENCODING option, when it dispatches the COPY to QEs.

The COPY TO handling wasn't quite right, even before this patch. It showed
up as regression failure in the src/test/mb/mbregress.sh 'sjis' test. When
client_encoding was set with the PGCLIENTENCODING, however, it wasn't set
correctly in the QEs, which showed up as incorrectly encoded COPY output.
Now that we always set it to match the database encoding in QEs, that's
moot.

While we're at it, change the mbregress test so that it's not sensitive to
row orderings. And make atmsort.pm more lenient, to recognize "COPY
<tablename> TO STDOUT", even when the tablename contains non-ascii
characters. These changes were needed to make the src/test/mb/ tests pass
cleanly.

Fixes https://github.com/greenplum-db/gpdb/issues/5241.

Discussion: https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/WPmHXuU9T94/gvpNOE73FwAJReviewed-by: NPengzhou Tang <ptang@pivotal.io>