GRAPH_TABLE: aggregates/window/set-returning functions in COLUMNS crash the backend

Hi,

While testing SQL/PGQ I found that putting an aggregate, window
function, or set-returning function in the COLUMNS list of a
GRAPH_TABLE query crashes the backend.

Minimal reproducer:

CREATE TABLE v (id int PRIMARY KEY);
INSERT INTO v VALUES (1);
CREATE PROPERTY GRAPH g VERTEX TABLES (v);

SELECT max(c) FROM GRAPH_TABLE (g MATCH (x IS v) COLUMNS (count(*) AS c));
On an assert-enabled build this trips

TRAP: failed Assert("econtext->ecxt_aggvalues != NULL"),
File: "execExprInterp.c", Line: 1969
and on a non-assert build it fails at execution with

ERROR: Aggref found in non-Agg plan node
A window function in COLUMNS behaves the same way; a set-returning
function is silently accepted and produces nonsensical results.

Root cause: transformRangeGraphTable() (parser/parse_clause.c)
transforms the COLUMNS expressions with EXPR_KIND_SELECT_TARGET, which
permits aggregates, window functions and SRFs. GRAPH_TABLE has no
machinery to evaluate them, though: rewriteGraphTable.c copies the
COLUMNS target list verbatim into a freshly built subquery whose
hasAggs/hasWindowFuncs flags are never set, so the planner builds no
Agg/WindowAgg node and the Aggref/WindowFunc reaches the executor.
(As a side effect p_hasAggs also leaks into the enclosing query,
yielding spurious "must appear in the GROUP BY clause" errors for some
other COLUMNS shapes.)

These constructs are not meaningful in a GRAPH_TABLE COLUMNS list, so
the attached patch rejects them at parse-analysis time, the same way
every other non-aggregating context does. It adds a dedicated
EXPR_KIND_GRAPH_TABLE_COLUMNS and wires it into the aggregate, window
and set-returning-function checks, producing errors such as

ERROR: aggregate functions are not allowed in GRAPH_TABLE COLUMNS
Plain column references and subqueries are unaffected (subqueries
continue to be rejected as before). A regression test is added to
graph_table.sql, and "make check" passes.

This is present on master and in the PG19 beta.

Thanks,
Ewan Young