Fix!: Inconsistent behaviour when a macro returns a list containing a single array vs multiple arrays

[erindru]

Closes #4536

Prior to this, the following behavior occurred:

>>> from sqlmesh.core.macros import MacroEvaluator
>>> from sqlglot import parse_one
>>> me = MacroEvaluator()

>>> me.transform(parse_one("select @each([1], a -> [@a])")).sql()
'SELECT ARRAY(1)' 

>>> me.transform(parse_one("select @reduce([[1]], (x,y) -> x + y)")).sql()
'SELECT ARRAY(1)' 

>>> me.transform(parse_one("select @reduce(@each([1, 2], a -> [@a]), (x,y) -> x + y)")).sql() 
'SELECT ARRAY(1) + ARRAY(2)'

>>> me.transform(parse_one("select @reduce(@each([1], a -> [@a]), (x,y) -> x + y)")).sql() 
'SELECT 1'

That last item is unexpected, it should be SELECT ARRAY(1) because @each returns 1 item of type array.

Unfortunately, _norm_var_arg_lambda() assumes this item is varargs and unpacks it, rather than passing it as-is.

Sometimes, we do actually want it to be unpacked though. If we didnt, select @each([1, 2], a -> [@a]) would result in SELECT ARRAY(ARRAY(1), ARRAY(2)) instead of SELECT ARRAY(1), ARRAY(2).

So this PR wraps the output of a macro function in an extra exp.Array to prevent _norm_var_arg_lambda() from treating it as varargs, but only if it's being used as input to another function, which preserves the semantics of still unpacking it for a SELECT column list.

[tobymao]

is this breaking?

[erindru]

I guess every bug fix is breaking if someone was depending on the buggy behaviour