Build and ship shim.cu file as LTOIR

[brandon-b-miller]

Closes #19362

[bdice]

A thought on naming for a future PR: do we want to rename "shim" to something like "fragment"? A shim sounds like it acts between two libraries to normalize API differences. In my understanding we're providing cuDF-friendly building blocks for Numba kernels to use, which feels more like a fragment ... or a library of device functions?

[bdice]

@brandon-b-miller I'd like to see some kind of performance assessment here before merging but I don't want to block work on #18453. I'm okay with doing that assessment post-merge if you and @vyasr agree to it.

[brandon-b-miller]

@bdice that seems reasonable to me. While technically independent, It probably would be more meaningful to benchmark the strings kernels after both this PR and the NRT PR are merged, as the NRT PR's incref's and decrefs might add a lot to the delta between LTOIR on/off. I'm happy to take that on. I'd imagine stuffing a UDF full of a bunch of chained operators might be a good place to start.

[brandon-b-miller]

A thought on naming for a future PR: do we want to rename "shim" to something like "fragment"? A shim sounds like it acts between two libraries to normalize API differences. In my understanding we're providing cuDF-friendly building blocks for Numba kernels to use, which feels more like a fragment ... or a library of device functions?

Originally when this file was conceived, it really was just an interop layer between libraries - it mostly forwarded function calls from the numba ABI to methods of cudf::string_view. It's more than that now though and contains groupby functions that aren't really shims, they're full implementations. The files we compile into the final shipped object could stand to be separated out a bit in that sense. But there's at least a little bit of genuine shimming going on WRT the string functions.

[brandon-b-miller]

/merge