Use builders for GroupBy initialization and updates

[lbooker42]

Similar to #2852, change GroupByChunkedOperator to use RowSetSequentialBuilder during the initial creation of the groupBy table.

Closes #2873

Zulu11.54+23-CA (build 11.0.14+9-LTS) on MacOS, M1                
Rows        Buckets    groupBy (ms)    groupBy_opt (ms)    speedup
100,000,000 100        1,754           1,485               15.3%
100,000,000 25,000     106,402         11,268              89.4%
100,000,000 1,000,000  32,800          27,687              15.6%
                
                
Zulu17.34+19-CA (build 17.0.3+7-LTS) on MacOS, M1                
Rows        Buckets    groupBy (ms)    groupBy_opt (ms)    speedup
100,000,000 100        1,518           1,485               2.1%
100,000,000 25,000     93,826          10,995              88.3%
100,000,000 1,000,000  3,313           22,397              48.3%

[rcaudy]

As-written, this only speeds up the instantiation pass. For partition-by, since we already needed to keep track of adds, removes, and modifies each cycle, changing update processing was a no-brainer. Do you think it would be worthwhile to start using random builders in updating processing to track adds and removes in group-by? I suspect the trade-off to be worth it.

[rcaudy]

A thing I've just thought of for group-by and partition-by. If we're using initial groups and !preserveEmpty, we might be orphaning empty builders in the addedBuilders sources indefinitely, since we only do any work with the ones that make it into the initial row set. I'm not sure it's a big deal, but it's not optimal.

I think we could pass the max slot used into propagateInitialState to allow the code to address this.

[rcaudy]

I think this is basically ready to merge, if nightlies look good. Minor nitpicks only.