Replace parts of cub::Traits by numeric_limits and deprecate those

[bernhardmgruber]

cub::Traits and friends provide a mix of functionality that is also partially provided by the (CUDA) C++ standard library. There should not be multiple ways to query and define traits of types, so wherever a standard library facility exists, we should deprecate that part in cub::Traits.

The initial goal was to get rid of cub::Traits by replacing as much as possible by cuda::std::numeric_limits and internalizing the rest. The rest turned out to be some bit twiddling utilities mostly used by radix sort. However, after a while, I noticed that those utilities may actually be nice to use outside CUB and some code search results indicate that:

• cub::Traits: https://github.com/search?type=code&q=cub%3A%3ATraits%3C (152 hits)
• cub::NumericTraits: https://github.com/search?type=code&q=cub%3A%3ANumericTraits%3C (82 hits)
• cub::BaseTraits: https://github.com/search?type=code&q=cub%3A%3ABaseTraits%3C (31 hits)
• cub::FpLimits: https://github.com/search?type=code&q=cub%3A%3AFpLimits%3C (52 hits)

So I considered re-exposing the twiddling functionality as a new trait to get the unsigned bits of a type and to twiddle-in/out. However, I later realized that cub::Traits serves even more uses:

• traits and limits (those could be replaced by libcu++ cuda/type_traits and cuda/std/limits)
• bit twiddling utilities (mostly for radix sort)
• specializing cub::Traits with user defined types to enable radix sort for them.

The last use case is the most problematic, since users rely on injecting custom data types into CUB and that CUB algorithms are going to ask cub::Traits about that type. So changing any cub::Traits<T>::Max() to cuda::std::numeric_limits<T>::max(), or changing cuda::Traits<T>::CATEGORY == FLOATING_POINT to cuda::is_floating_point<T> anywhere in CUB (or any piece pulled into CUB from Thrust or libcu++), is a breaking change. This puts us in a very bad corner, and is likely already broken today, since we also rely on traits and limits from libcu++ in all kinds of places.

An example of such a specialization is pytorch registering their bfloat16 wrapper c10::BFloat16 to CUB this way. We do a similar thing in our unit test to work around half/bfloat16 not having operators for host code before CTK 12.2.

I think we should at least deprecate all parts of cub::Traits that are covered by libcu++ limits or traits. Users should get a deprecation warning when using cub::Traits to ask for a type trait or limit.

Beyond that, I can think of:

1. Eager: deprecate and eventually remove cub::Traits . This way, every user providing a specialization of cub::Traits sees a loud warning that they should specialize limits, traits etc. For the bit twiddling, we should introduce a new trait restricted to just that functionality or just drop the functionality completely.
2. Conservative: retaining cub::Traits limited to the bit twiddling functionality. User code specializing it and also adding information on limits etc. will continue to work, but CUB algorithms using/moving to libcu++ limits/traits will no longer regard the user provided information. That leaves us at risk of inconsistency when refactoring CUB algorithms.
3. Half-way: turning cub::Traits into an alias to a template inside a detail namespace. This way, user code using it to query information or do bit twiddling continues to work, but users would get an error when they would specialize it.

Now I know that radix sort has a differente API (decomposer) as well to describe how a key type can be turned into bits, so maybe using cub::Traits to buy a new type into radix sort is actually a hack and we may want to prevent users from doing that anyway. In many instances it's also probably used to work around limitations of the built-in half and bfloat16 types.