[FEA]: Determine how to generalize `__device__` or SM code path error reporting.

### 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

CCCL

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

libcudacxx currently uses [this pattern](https://github.com/NVIDIA/cccl/blob/af1641fdf45a742c3e6077a378d0327239c84a0d/libcudacxx/include/cuda/std/detail/libcxx/include/__cuda/ptx/parallel_synchronization_and_communication_instructions_mbarrier.h#L131C1-L151C32) for generating compile time errors for functions that need to be declared, but cannot be used in certain code paths.

The linked code is fairly verbose, but is a pattern we want to use more often when enabling more CUDA specific features with intrinsics that are only available under certain versions of CTK/PTX and etc.

### Describe the solution you'd like

We should be able to turn the above into a macro. NV_IF_TARGET cannot be used to declare functions, so all behavior must be enclosable within function scope.

We should find out how to both provide a decent error message and a convenient interface. Jake helpfully crafted this example, which in my own testing is possible to make work, but we take hits on readability.
```
void foo(){
NV_IF_TARGET( NV_IS_DEVICE, ( do_device_thing()),
NV_IS_HOST, ( CCCL_UNSUPPORTED_IFTARGET_BRANCH(custom_reason_message))
}
```

Here is an example comparing the behavior of the approaches. https://gcc.godbolt.org/z/c15dY8qbf

### Describe alternatives you've considered

_No response_

### Additional context

_No response_