Prefer pg_any_to_server/pg_server_to_any over pg_do_encoding_conversion.

A large majority of the callers of pg_do_encoding_conversion were
specifying the database encoding as either source or target of the
conversion, meaning that we can use the less general functions
pg_any_to_server/pg_server_to_any instead.

The main advantage of using the latter functions is that they can make use
of a cached conversion-function lookup in the common case that the other
encoding is the current client_encoding.  It's notationally cleaner too in
most cases, not least because of the historical artifact that the latter
functions use "char *" rather than "unsigned char *" in their APIs.

Note that pg_any_to_server will apply an encoding verification step in
some cases where pg_do_encoding_conversion would have just done nothing.
This seems to me to be a good idea at most of these call sites, though
it partially negates the performance benefit.

Per discussion of bug #9210.

contrib/pg_stat_statements/pg_stat_statements.c

@@ -1458,11 +1458,9 @@ pg_stat_statements_internal(FunctionCallInfo fcinfo,
 				{
 					char	   *enc;
 
-					enc = (char *)
-						pg_do_encoding_conversion((unsigned char *) qstr,
-												  entry->query_len,
-												  entry->encoding,
-												  GetDatabaseEncoding());
+					enc = pg_any_to_server(qstr,
+										   entry->query_len,
+										   entry->encoding);
 
 					values[i++] = CStringGetTextDatum(enc);