Summary:
There was a bug in our aggregate support implementation. In general, by
the execution time column references in the aggregate functions are
represented as the position number in the underlying plan's target list.
When aggregate is pushed down with the scan, the target list position
is translated to the column number of the scanned relation.

The Postgres optimizer may modify a column reference multiple times, but
in most cases a column reference is initialy represented as the column
number of some relation, as relation infos, including column lists, are
retrieved by the parser. Later on optimizer removes unused columns from
the relation infos, and updates the references accordingly, but the
initial number is stores with the reference. Hence we conveniently used
it to update the reference when we pushdown.

However, there are exceptions. Subqueries are planned independently, and
aggregates on subquery results initially refer the targets of the
subquery, not columns of some table. In most of the cases it does not
create a problem, because we do not push aggregates into subqueries. But
sometimes optimizer can figure out that subquery is trivial and flatten
it, but references' initial numbers are still point to subquery and
therefore update of pushed down column reference is incorrect.

This diff no longer relies on the assumption that the initial column
number stored with the reference is correct. It pulls the referenced
target list entry from the scan and finds there correct column number.
Jira: DB-13426

Test Plan: ./yb_build.sh --java-test 'org.yb.pgsql.TestPgRegressFeature#testPgRegressFeature'

Reviewers: jason, aagrawal, mtakahara

Reviewed By: mtakahara

Subscribers: yql

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D41415