[RFC] Decide the fate of CUB iterators

Since Thrust iterators have been (mostly) superseded by iterators in the `cuda` namespace, we should ask ourselves how the future of CUB iterators should look like. In its current state, they are outdated, follow the obsolete Thrust iterator model, and lack any integration with the C++20 iterator model. We either have to invest in their maintenance or replace/drop them.

The following iterators are offered by CUB:

1. `ArgIndexInputIterator`
2. `CacheModifiedInputIterator`
3. `CacheModifiedOutputIterator`
4. `TexObjInputIterator`

`ArgIndexInputIterator` is basically a `zip_iterator>`, so we could argue that we already have a replacement. Its use in CUB is moderate and probably easy to replace. I would recommend to replace all uses in CUB and deprecate it with a note towards using zip and counting iterator as replacements.

`CacheModifiedInputIterator` and `CacheModifiedOutputIterator` wrap a cache modifier `Mod` and a raw pointer to `VT` and apply the cache modifier when reading or writing through the iterator. Cache modifiers used to be relevant on older generation GPUs, but their impact on GPUs currently support by CCCL is questionable. We should ask internal experts on the current relevance and impact of cache modifiers and either drop those iterators or migrate them properly to the `cuda` namespace and the C++20 iterator model.

`TexObjInputIterator` wraps a pointer to `T` and uses a texture object when reading from the iterator. As with the cache modified iterators, such techniques used to be important, but may be less so on modern GPUs. We should similarly find out whether reading through texture memory provides relevant benefits nowadays and then either drop or migrate the iterator.