Draft: Second iteration of radix sort instances, using `record RadixSortLSDPlan`

[stress-tess]

Part of #1338 Very basic iteration, all we do here is wrap the parameters for RadixSortCore into a record and pass them in

I think eventually we want to allocate the arrays a and temp and store them in RadixSortLSDPlan as well. I'm not sure how this will affect performance because right now, i'm passing plan in as a const and I don't we'll be able to do that then since those arrays will be changing

I think once i figure out the above, we'll build some sort of map so we can cache RadixSortLSDPlans. That way if we request one with the same configuration as an existing one, we can reuse the existing one. This'll save us the cost of allocating and deallocating arrays for repetitive sorts with the same configuration. Though we'll prob want to cap this somehow to avoid too much memory being used by the cache

Once again, ak.sort is my guinea pig function

>>> a = ak.randint(1, 15, 10)
>>> a
array([13 11 4 5 6 11 4 8 8 6])

>>> ak.sort(a)
array([4 4 5 6 6 8 8 11 11 13])

>>> ak.sort(a, bits_per_digit=4)
array([4 4 5 6 6 8 8 11 11 13])

>>> ak.sort(a, num_tasks=22, bits_per_digit=4)
array([4 4 5 6 6 8 8 11 11 13])

[mhmerrill]

just so it doesn't get lost:

• we had talked about making a makeRadixSortLSDPlanMsg message to the server so there is one place to provide the parameters for making a plan.
• and then all of the places where RadixSortLSD is called we would call chooseRadixSortLSDPlan, this would remove the parameters from all the messages for making a plan.

[Ethan-DeBandi99]

This work did not yield the results expected. Closing this because nothing further is being done at this time.