Extend CUB/Thrust magic namespace with NVHPC

[bernhardmgruber]

Recently, in #2664 we also introduced different behavior depending on the compiler used to translate CUDA kernels. This can get us into similar troubles when object files with device code from different compilers are linked together, because depending on how the linker chooses between the available weak symbols, the host side kernel setup might not match what the device-side entry point expects.

Because mixing object files with device code from different compilers is a supported scenario, we should guard Thrust/CUB symbols against such a mix. CUB and Thrust already use an inline namespace containing the list of SM architectures we compile for. This avoids/detects errors when object files compiled for different architectures are linked together. This list should be extended by whether NVHPC is used or not.