Improve argument filtering for CUDA sub-compilations targeting NVPTX

[Artem-B]

From #70740 (comment)

The current filtering mechanism is gross. We have code that does the following error checking for a lot of options and there are more and more of them. It is nearly infeasible to enumerate them.

if (!Triple.isXXX()) { err_unsupported_opt_for_target } else handle
When such an option is used in clang++ --cuda-path=/usr/local/cuda -x cu /dev/null -c -nocudainc -nocudalib $option, we will get an error for NVPTX.

-mcmodel= turned out to be an issue just because we add this option globally.

https://reviews.llvm.org/D105226 introduced a special case to exclude NVPTX for -fbasic-block-sections=, so this has a precedent, but we should figure out a way to handle the target-specific options in a more elegant way.

I do not know whether we should use something similar to -fembed-bitcode's list.

[llvmbot]

@llvm/issue-subscribers-clang-driver

Author: Artem Belevich (Artem-B)

From https://github.com//pull/70740#issuecomment-1786180822

>The current filtering mechanism is gross. We have code that does the following error checking for a lot of options and there are more and more of them. It is nearly infeasible to enumerate them.
>
> if (!Triple.isXXX()) { err_unsupported_opt_for_target } else handle
When such an option is used in clang++ --cuda-path=/usr/local/cuda -x cu /dev/null -c -nocudainc -nocudalib $option, we will get an error for NVPTX.
>
> -mcmodel= turned out to be an issue just because we add this option globally.
>
> https://reviews.llvm.org/D105226 introduced a special case to exclude NVPTX for -fbasic-block-sections=, so this has a precedent, but we should figure out a way to handle the target-specific options in a more elegant way.
>
> I do not know whether we should use something similar to -fembed-bitcode's list.

[Artem-B]

Stack protector options: #70799