Tuning API publication cleanup work

[bernhardmgruber]

This issue tracks cleanup and finalization tasks to be performed once we are done with publishing all tuning APIs.

Cleanup tasks:

• Use a more descriptive name for the C2H policy tests. They are currently called e.g. "SelectPolicy"
• Make sure every sub policy is also checked for aggregate and semiregular
• Rename FindPolicy to FindIfPolicy #9689
• @davebayer: wouldn't <unknown BlockScanAlgorithm(10)> be more readable than <unknown BlockScanAlgorithm: 10>? I feel like the X(Y) is used by compilers for enum nttps. We are going to remove the value, to make the stringification logic simpler (makes std::format support easier later)
• Re-check whether all agent policies have been deprecated
• Re-check whether all dispatchers have been deprecated
• Re-check whether all chosen policy names are consistent
• Make sure the deprecation warnings are consistent
• The Tuning paragraph in the docs does have the wrong syntax and does not render correctly, see for example: https://nvidia.github.io/cccl/unstable/cub/api/structcub_1_1DeviceRadixSort.html#performance: Fix doxygen tuning doc headings #9713
• Similarly, find better wording for the env_api tests where a custom policy selector is provided. They are currently called e.g. "cub::DevicePartition::If env-based API with tuning": Rename policy selector tests #9715
• Make sure all tuning policy documentation comments follow the same style
• Reorder SegmentedSortPolicy members: Swap small_segment and medium_segment in SegmentedSortPolicy #9716
• @davebayer: why do we have the num_ prefix in one case, but not for radix_bits? Remove num_ from tuning policy members #9717
• Deprecate cub::ChainedPolicy: Deprecate cub::ChainedPolicy #9744
• Make sure tuning policies appear in the CUB API reference docs: https://nvidia.github.io/cccl/unstable/cub/api/index.html: Add tuning policies to CUB API docs #9745
• Rewrite catch2_test_vsmem.cu to use policy selectors instead of a dispatcher struct Postponed to Track future deprecations and breaking changes for CCCL 4.0 #3701
• Strongly consider providing default values for all members of a tuning policy. This came up a few times, but I think it's hard to do in the general case, since we don't know for which CC we are creating the tuning policy. I asked again on Slack and people couldn't come up with a good rule for how to pick default values. I will leave this for now.