Add experimental make_strings_children utility

[davidwendt]

Description

Adds new cudf::strings::detail::experimental::make_strings_children which uses the offsetalator to build output columns. The current d_offsets member required by the given functors no longer stores sizes and offsets but is now split into d_sizes and d_offsets where d_sizes is computed in the first pass and then d_offsets is set to an offsetalator for building output in d_chars.

Once all the uses of make_strings_children (~50 or so) are converted to use the experimental implementation, this will replace the old implementation and the 'experimental' namespace will be removed.

This PR includes 2 changes, repeat_strings and concatenate (per row) since each use different overloaded make_strings_children functions to verify the code does not break any current tests.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[karthikeyann]

The functor is passed by value. The members stored in them won't be passed back to caller. The caller's functor object scope won't matter. Do we need to change the functor members to functor's arguments?
The user anyway should be aware of passing functor by value or reference. So, the scope of these members should be clear that it's only internal to make_strings_children.
(Also, increasing arguments to functor isn't desirable).

[davidwendt]

The functor is passed by value. The members stored in them won't be passed back to caller. The caller's functor object scope won't matter. Do we need to change the functor members to functor's arguments? The user anyway should be aware of passing functor by value or reference. So, the scope of these members should be clear that it's only internal to make_strings_children. (Also, increasing arguments to functor isn't desirable).

You are right. I had forgotten about the functor is passed by value so there are 2 independent copies and therefore really 2 scopes for the data.
Also, I looked through the 50 or so usages and the additional parameters would to troublesome for a significant number of implementations. Like where member utility functions use the members and now would need to forward these parameters. The concatenate implementation in this PR is an example of that.

I'm happy to change it back to member variables unless there is more compelling reason for keeping them as parameters.

Requiring a base-class does not really help much here in my opinion since they would hide the members in a separate header file that are directly and frequently being referenced by the functor logic. I'd like to keep them close the logic that uses them.

Also, I want to preserve the raw kernel introduced here for calling the functors. This allows functors to legally use shared memory and warp and block intrinsics, etc which are considered UB in thrust lambdas/functors.

[bdice]

@davidwendt I’m not able to re-review until next week but please feel free to move forward with your plan described above. I proposed the alternative structure but I’m happy with your reasoning for rejecting that proposal.

[shrshi]

A clarification on the docs -

[shrshi]

Looks good to me!

[mythrocks]

LGTM!

[davidwendt]

/merge