SQL/PGQ: Support multi-pattern path matching in GRAPH_TABLE

Hi hackers,

Now that the SQL/PGQ core has been committed, I'd like to propose
extending GRAPH_TABLE to accept multiple path patterns in the MATCH
clause, i.e. the comma-separated form:

SELECT ... FROM GRAPH_TABLE (g
MATCH <path_pattern_1>, <path_pattern_2>, ...
COLUMNS (...)
);

This shape is not supported today — the parser rejects it with

multiple path patterns in one GRAPH_TABLE clause not supported

and the rewriter asserts that the path_pattern_list has exactly one
entry. Among the features that are not yet covered, I think this one
has the highest practical need: many realistic graph queries express
joins and star-shaped traversals most naturally as multiple
comma-separated patterns, and without it those queries have to be
rewritten into more awkward forms. The attached patch lifts the
restriction and wires the existing path-rewriting pipeline through
the list of path patterns.

What the patch does
-------------------

Parser side: the error that rejected multi-pattern MATCH is
removed, so such queries now reach the rewriter.

Rewriter side: each path pattern is processed as its own chain,
so adjacency linking never crosses a path boundary. Element
variables that share a name across paths are still merged into
the same element — shared variables produce joins, disconnected
paths produce cross products.

An earlier version flattened all element patterns into a single
list, but that treated elements from adjacent paths as adjacent
within one path and broke on vertex-vertex boundaries. The
per-path approach is the minimal fix; a more principled cross-path
join construction is left for this thread to settle.

Examples
--------

Shared variable (join):

MATCH (a IS vl1)-[e1 IS el1]->(b IS vl2),
(b)-[e2 IS el2]->(c IS vl3)

-- b is shared -> the two patterns are joined on b.

Star/hub:

MATCH (a IS vl1)-[]->(b IS vl2),
(a)-[]->(c IS vl3),
(d IS vl2)-[]->(a)

-- three patterns meeting at a.

Disconnected patterns (cross product):

MATCH (a IS vl1), (b IS vl3)

Partial connection mixed with a disconnected piece:

MATCH (a)-[]->(b), (b)-[]->(c), (d IS vl1)

Status
------

I would appreciate feedback along these axes:

* standard conformance — whether the shape and the handling of
multi-pattern MATCH are aligned with SQL/PGQ (ISO/IEC 9075-16);
* semantics — whether the behavior on shared variables,
disconnected patterns, and their combinations is the right one;
* functionality — coverage gaps, cases the patch does not yet
handle, or constructs that should be rejected but currently are
not (and vice versa);
* robustness — correctness under edge cases, error handling, and
anything that could destabilize the existing GRAPH_TABLE path;
* code shape — whether generate_queries_for_path_pattern() has
grown large enough that the per-path body should be factored
out into a helper. I kept the function intact in this round,
but would gladly split it if reviewers prefer that.

Review comments, objections, and alternative approaches are all
welcome — please don't hesitate to push back on anything that looks
off.

Thanks,
Henson

Reference to the SQL/PGQ main thread:

https://postgr.es/m/CAAAe_zAEEAb=piH4n-mZUhqcL=oKbDv4v-_7C_7KyXroem=HUg@mail.gmail.com