[FEA]: Headers that don't support NVRTC should emit diagnostic

### Is this a duplicate?

- [x] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this request and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)

### Area

General CCCL

### Is your feature request related to a problem? Please describe.

As a user of CUB and NVRTC, it is easy to mistakenly include the `` header instead of the more specific header like ``. [Improved documentation](https://github.com/NVIDIA/cccl/issues/5404) would help with this, but a safety net that just detects it and tells me what to do instead would be better.

The latter will succeed as we explicitly test and support CUB block/warp primitives within CUDA C++ kernels compiled with NVRTC.

The former will fail since `cub.cuh` contains host code and NVRTC can only compile device code.

The failure mode when this happens can be confusing because you're likely to get an error like this:
```
nvrtc_cli fatal : nvrtcCompileProgram failed: NVRTC_ERROR_COMPILATION
/opt/compiler-explorer/libs/cccl/v3.0.0/thrust/thrust/system/cuda/detail/core/triple_chevron_launch.h(61): error: A function explicitly marked as a __host__ function is not allowed in JIT mode
THRUST_RUNTIME_FUNCTION triple_chevron(
```

It would be far more helpful to get an error saying that this header isn't supported with NVRTC and point people to what _is_ supported.

### Describe the solution you'd like

The `cub.cuh` header (and any other public header that doesn't support NVRTC) should `#error` with an informative diagnostic when it detects compilation with NVRTC.

### Describe alternatives you've considered

_No response_

### Additional context

_No response_