feat(udf): add support for builtin aggregate UDFs

[cpcloud]

Adds support for builtin user-defined aggregate functions. This came up as a use case during a blog post I am authoring on the expanded array functionality for BigQuery that is landing in ibis 7.0.0. The blog post no longer uses this feature, but it's a useful one regardless.

Depends on #7122.

[jcrist]

Overall this seems pretty good.

One thing I thought about while reviewing this is that maybe grouping functionality by UDF implementation (builtin, pyarrow, ...) rather than kind (scalar, agg, ...) would make more sense? So it'd be udf.builtin.scalar instead of udf.scalar.builtin?

Most/all backends should be able to support udf.builtin for exposing builtin functionality, but the other UDF types would be rarer to support. If a user wants to expose a builtin function directing them to udf.builtin.* rather than udf.*.builtin might make things clearer since that functionality is all grouped together?

No need to deal with this now/here if we want to make this change, but it came up while reviewing it so I thought I'd mention it.

[cpcloud]

One thing I thought about while reviewing this is that maybe grouping functionality by UDF implementation (builtin, pyarrow, ...) rather than kind (scalar, agg, ...) would make more sense? So it'd be udf.builtin.scalar instead of udf.scalar.builtin?

Yeah ...

I went back and forth on this a bit when building the API.

I don't have a super strong opinion, but my thinking is based on how people talk about the separate kinds of UDFs in other systems.

The first point of departure in my experience has always been the shape of the output: scalar, aggregate, or tabular, and so that was the first level of namespacing I chose.

I think but am not entirely sure, that this makes implementation a bit cleaner because there's more overlap in behavior in the scalar category than the builtin category. That's not really based on thorough analysis of anything though, just my intuition.

I think when I am reading UDF signatures the first thing I want to know is where I can use it, and scalar/agg/tabular is a stronger determinant of where I can call it than whether the thing is builtin or not.

[jcrist]

I think when I am reading UDF signatures the first thing I want to know is where I can use it, and scalar/agg/tabular is a stronger determinant of where I can call it than whether the thing is builtin or not.

That's a good point - I think for reading existing udfs scalar/agg/tabular is more critical, but for writing whether it's builtin/pyarrow/pandas feels more critical. I also don't have strong thoughts on this, what we have now seems fine, we can always reorg later if it a different layout becomes clearly better.

[jcrist]

Excellent, excited to use this new functionality

[jcrist]

Nice example