feat: Support variadic arguments in the middle of a function signature

[reneesoika]

Description

Follow-up to #9361. This PR adds support for a variadic argument anywhere in the function signature. There can still be only one variadic argument in the function signature.

This change is being made because we currently cannot support variadic UDAFs with initial arguments. Allowing a variadic argument in the middle removes this restriction.

The main changes to enable this feature are in UdfIndex. The tree of parameter types is now based on pairs of parameters, with one parameter from the left half of the parameter list and one parameter from the right half. This structure ensures the loop for variadic arguments is always at the bottom of the tree, eliminating most edge cases. There is also a new rule to determine function precedence:

If two methods exist that match given the above rules, return the method with the variadic argument in the later position.

The number of nodes generated is quadratic with respect to the number of parameters in the function (only for variadic functions), but we only generate the tree once at startup. The number of nodes generated is not excessive unless there is a grossly absurd number of arguments (see graph). Currently, the only way to have a function with this many arguments is to have many initial arguments, as Java supports up to 255 arguments for a method. Resolving a function still takes linear time.

How UdfIndex now works is documented more thoroughly in comments. Other changes are removing exceptions thrown for var args in the middle or tests.

Testing done

Added unit tests and QTTs for var args in the middle.

Reviewer checklist

• Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
• Ensure relevant issues are linked (description should include text like "Fixes #")

[jzaralim]

lgtm thanks @reneesoika

[reneesoika]

@jzaralim I noticed a minor bug that would cause the function call to be ambiguous, which I just pushed a commit to fix.

If you had these two function signatures:

f(A first, int second, boolean... third)
g(B first, int... second, boolean third)

f and g would end up on different branches, so the comparison of variadic position in Node#update() would never be executed, leading to an ambiguous function call exception when both match.

I moved all the precedence rule comparisons into the same comparator, which fixes the issue. In the original UdfIndex, I think the generics rule was separate from the comparator because two functions with different numbers of generics could never be the value of the same node. IMO, putting all the rules into the same comparator is going to be less bug-prone since the precedence rules must always be followed, even if they aren't all necessary in a particular spot.