fix(rust/sedona-functions): Let ST_Collect_Agg() on a Geography return a Geography

[yutannihilation]

Fix #280

I guess there are more functions that need similar fix, but this only addresses ST_Collect_Agg(), which looks straightforward.

> SELECT ST_Collect_Agg(ST_GeogPoint(0, 1));
┌─────────────────────────────────────────────────┐
│ st_collect_agg(st_geogpoint(Int64(0),Int64(1))) │
│                    geography                    │
╞═════════════════════════════════════════════════╡
│ MULTIPOINT((0 1))                               │
└─────────────────────────────────────────────────┘

[paleolimbot]

Thank you!

I have a slight preference for registering two kernels to do this (or rather: the same parameterized kernel twice)...the dispatch code added here duplicates some logic we have to do the same thing already. I know it is silly but struct STCollectAggr { is_geography: bool} + vec![Arc::new(STCollectAggr {is_geography: true}, STCollectAggr {is_geography: false})], would let us reuse that.

There are a few unrealized benefits of the kernel system that aren't well documented yet...we can do an optimization where we resolve the kernel at the end of the planning stage to prevent the kernel from being resolved for every batch during execution (which is what happens now). We could also leverage this to validate documentation (the kernel list is basically a list of mappings from input type -> output type).

[paleolimbot]

This is very similar to what the SedonaAggregateUDF does when resolving the SedonaAccumulator based on the input arguments.

[yutannihilation]

Thanks for the hint, I'll implement so! (Probably later this week or next year)

[paleolimbot]

Thank you!