WIP: add FindCUDAToolkit.cmake module

This module is intended for consolidating the CUDA Toolkit discovery location into one file, that is affected by exactly one variable CUDA_ROOT. The goals listed here may not all be relevant, this can be gutted, moved, refactored, or ignored in favor of a better solution. Affected components

• FindCUDA.cmake will remain as is to avoid backwards compatibility problems that changes may introduce. Can FindCUDA.cmake use this? See TODO comments, the main question is what exactly is going on with the CMAKE_CROSSCOMPILING checks in that file. While consolidation of the find logic is nice, I think FindCUDA.cmake not getting this is OK. It's supposed to be dying a slow death now anyway right?

• Beyond scope of this MR, CUDACXX=clang++ changes if needed can be added in future. Can this be used in support of CUDACXX=clang++? See the long and skinny. The main dilemma being that at that stage of CMake setting up, find_package(CUDAToolkit) => find_library(cudart) = problem. It is, however, possible to detect

  if (NOT DEFINED CMAKE_FIND_LIBRARY_PREFIXES)
      find_path(...)  # more work, but safer
  else()
      find_library(cudart)  # as currently done
  endif()

  The idea being that since CUDACXX=clang++ needs the CUDAToolkit_ROOT_DIR very early. By moving to a find_path, it makes it possible to include(${CMAKE_CURRENT_LIST_DIR}/FindCUDAToolkit.cmake), which is probably closer to the right thing to do.

• See previous. How is CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES set, and can this be used for that too?

• No, use CUDAToolkit_ROOT. Is CUDA_ROOT CMP0074 compliant? The goal was to use the most natural one, and ideally make FindCUDA.cmake depend on this. But CUDAToolkit_ROOT is obnoxious. Can we make an exception?

• Is it appropriate to FATAL_ERROR when CUDA_ROOT does not specify a valid CUDA Toolkit location? Or should the default installation paths then be searched?

  • Related: is there too much documentation here? Is it important to describe the exact search behavior, or is it assumed that interested parties will read the source code?

• Is the numerical sort of potential installed toolkits worth it? I personally would greatly prefer the behavior is to try later cuda versions first, but I'm not sure if it's worth the complexity when we can just as easily say "define CUDA_ROOT" if you have multiple installs.

If we want to move forward with this approach, the would-be FindCUDALibs.cmake would depend on this module so that it can issue its find_library calls and add the imported interface targets.

I would like to get feedback here first, and if this is a direction we want to take things then I will solicit testing from macOS and Windows users (I only tested linux).