Fully support nested types in cudf::contains

[ttnghia]

This extends the cudf::contains API to support nested types (lists + structs) with arbitrarily nested levels. As such, cudf::contains will work with literally any type of input data.

In addition, this fixes null handling of cudf::contains with structs column + struct scalar input when the structs column contains null rows at the top level while the scalar key is valid but all nulls at children levels.

Closes: #8965
Depends on:

• Two-table comparators with strong index types #10730
• Strong index types for equality comparator #10883
• Refactor cudf::contains, renaming and switching parameters role #10802
• Refactor cudf::contains #10997
• [FEA] Support contains with template key types NVIDIA/cuCollections#172
• [FEA] Support pair_contains in static_map and static_multimap NVIDIA/cuCollections#173
• [FEA] Share code between left_semi_anti_join, cudf::contains, and set operations #11037
• Add column constructor from device_uvector&& #11356

[ttnghia]

Alright, this PR is awakened. Now it has a totally new implementation, which is just around 10 LOC.

[davidwendt]

Just curious why this detail function returns a device_uvector instead of a column?
Will the result ever be larger than what a column supports?

[ttnghia]

That detail::contains(table_view, table_view) function was initially refactored out of semi-join (#11100). Now, it is also used in several other places but the result is only used for temporary computation and never be returned to the user. Thus, device_uvector is enough at this time.

It is still unclear whether we will expose this function to the public.

[vyasr]

I would also say that (especially for internal APIs like this, but occasionally even otherwise) I prefer using a strongly-typed object like a device_uvector rather than the type-erased (and nullable) column. We have more information available and convey it. Even for public APIs I like uvectors when we don't need type erasure or nullability because the returned values are clearly defined.

[bdice]

This discussion is also related to #11356.

[bdice]

LGTM. I have only very minor suggestions at this point. Thank you!

[PointKernel]

LGTM

[ttnghia]

@gpucibot merge