Minor: Add sql test for UNION / UNION ALL + plans

[alamb]

Which issue does this PR close?

Related to #7695 and #7786

Rationale for this change

Add test for #7786 as well as an end to end verification for #7695

What changes are included in this PR?

2 new tests

Are these changes tested?

Are there any user-facing changes?

[alamb]

This test passes even without #7695 as the flattening happens in the SQL pass. #7695 move the flattening so it happens as part of the normal optimizer flow

[comphead]

Perhaps I'm wrong but why we have 2 set of AggregateExecs....

I ran the similar query in PG
EXPLAIN verbose SELECT firstname FROM scientist UNION (SELECT firstname from scientist UNION SELECT firstname || '_new' from scientist2);

QUERY PLAN
--
HashAggregate (cost=44.45..49.55 rows=510 width=32)
Output: scientist.firstname
Group Key: scientist.firstname
-> Append (cost=0.00..43.17 rows=510 width=32)
-> Seq Scan on public.scientist (cost=0.00..11.70 rows=170 width=218)
Output: scientist.firstname
-> Seq Scan on public.scientist scientist_1 (cost=0.00..11.70 rows=170 width=218)
Output: scientist_1.firstname
-> Subquery Scan on "*SELECT* 3" (cost=0.00..13.82 rows=170 width=32)
Output: "*SELECT* 3"."?column?"
-> Seq Scan on public.scientist2 (cost=0.00..12.12 rows=170 width=32)
Output: ((scientist2.firstname)::text \|\| '_new'::text)

There is only 1 set of agregation

[alamb]

Perhaps I'm wrong but why we have 2 set of AggregateExecs....

Because we haven't implemented #7786 yet :) Though it appears that @maruschin is working on it in #7788

[alamb]

Thanks @comphead and @jackwener