Plan table function invocation with table arguments

[kasiafi]

This PR adds the RelationPlanner part for table function invocation with table and descriptor arguments.
These types of arguments are not yet supported -- they cause the query to fail during the initial planning phase.

No docs or release notes required.

based on #14115

Example output from the PlanPrinter:
query:

SELECT * FROM TABLE(mock.system.different_arguments_function(
     INPUT_1 => TABLE(SELECT 'a') t1(c1) PARTITION BY c1 ORDER BY c1,
     INPUT_3 => TABLE(SELECT 'b') t3(c3) PARTITION BY c3,
     INPUT_2 => TABLE(VALUES 1) t2(c2),
     ID => BIGINT '2001',
     LAYOUT => DESCRIPTOR (x boolean, y bigint)
     COPARTITION (t1, t3))) t

fragment of the plan:

         └─ Project[]
            │   Layout: [some_column:boolean, expr:varchar(1), field:integer, expr_0:varchar(1)]
            │   Estimates: 
            └─ TableFunction[name = different_arguments_function]
               │   Layout: [some_column:boolean, expr:varchar(1), field:integer, expr_0:varchar(1)]
               │   Estimates: 
               │   Arguments:
               │   INPUT_1 => TableArgument{partition by: [expr], order by: [expr ASC NULLS LAST], pass through columns}
               │   INPUT_3 => TableArgument{partition by: [expr_0], prune when empty}
               │   INPUT_2 => TableArgument{row semantics, prune when empty, pass through columns}
               │   ID => ScalarArgument{type=bigint, value=2001}
               │   LAYOUT => DescriptorArgument{(X boolean, Y bigint)}
               │   Co-partition: [(INPUT_1, INPUT_3)]
               ├─ [INPUT_1] Project[]
               │  │   Layout: [expr:varchar(1)]
               │  │   Estimates: 
               │  └─ Project[]

[martint]

Instead of passing the whole map of node id -> name and having this method look it up, it would be cleaner to pass the intended name directly. At the end of the day, for each branch of recursion when visiting a child, there's only one name that's valid.

This means that the Context just just contain a single name that represents the "tag" associated with the subtree. If present, it will be prepended to the root of that subtree when printed. It also makes it more generic and allows for tagging any subtree (e.g., for a JOIN, we might want to tag the left and right differently), etc.

[kasiafi]

If the context had just a single tag instead of the map, I would have to process sources in a loop, creating a new context per child instead of just call processChildren.

However, my main reason for using a map by id was to make it more robust. The usual usage pattern for context is that we process the node, and then recursively process children, passing the same context. In the current design I can safely do it, as node ids are unique. If the context had just a tag, we would need to explicitly clear the context before the recursive call. It would be unintuitive for future contributors.

[martint]

If the context had just a single tag instead of the map, I would have to process sources in a loop, creating a new context per child instead of just call processChildren.

That's ok. It would make the intention much clearer.

However, my main reason for using a map by id was to make it more robust. The usual usage pattern for context is that we process the node, and then recursively process children, passing the same context.

That's an abuse of what "context" in the case of the visitor is meant to do. The context is supposed to be specific to the node being visited (e.g., in filter pushdown, it contains the effective filter applied to the output of the current node). Sometimes, it's just easy to pass the same object, but that's not necessarily the best option in all cases.

If the context had just a tag, we would need to explicitly clear the context before the recursive call.

No, it'd be better to just create a new context with the proper tag.

[martint]

It's strange for a table function to use a WindowNode.Specification. We should either move it out of WindowNode (preferable) or create a separate one (not ideal if they represent the same concept)

[kasiafi]

Extracted Specification.

[kasiafi]

@martint could you please take a look?

[kasiafi]

@martint I changed the PlanPrinter's context like you suggested. Please take a look.