What this does:

- it adds a ton of traces, that are more suitable to follow certain
  aspects of the code that raw gdb on the foreign_expr_walker
  recursive exploration of the parse tree.

- it modifies the code related to checking of collations. I don't
  really understand if it is a bug or if there's actually a conflict
  with collations and it is unsafe to push, but I tend to think it is
  indeed a bug as no collation should affect it.

- it allows for Row Expressions node push downs (T_RowExpr) in a very
  hacky way. Chances are that to do it properly it needs to continue
  with a recursive exploration of the tree from that node. This was
  preventing the whole aggregate function ST_AsMVt to be pushed down
  to the foreign server.

- it provides a crappy implementation of deparseRowExpr. It makes the
  planner happy to ship some SQL but it is not really valid and fails
  with an error on the remote end. It shall not confuse the
  representation in the EXPLAIN of ROW() with the SQL ROW() row
  constructor.

In short this just half-works, and we really need both halfs for it to
do something interesting. Nevertheless I think it is good to share, to
give an idea of the type of work to accomplish to finish this and
similar cases.

A row expression cannot be deparsed as ROW(...) cause otherwise column
names are lost when sending the deparsed query to the remote.

RowExpr may be present in the planner tree, as the optimizer may "pull
up" aggregation subqueries and it certainly does.

In particular, ST_AsMVT may produce different results or may miss the
geom column if column names are generated as f1, f2, ..., fn.

This solves that issue by deparsing the row expression as an alias and
embedding it into a subquery.

This is the intended syntax transformation in pseudo-code:

SELECT row_expr
FROM from_clause
WHERE where_caluse

  =>

SELECT alias
FROM (
  SELECT row_expr_fields
  FROM from_clause
  WHERE where_clause
) alias