ENH: Investigate alternate VkFFT backends

[tbirdso]

1. Vulkan
2. CUDA

[tbirdso]

The VkFFT backend is determined during CMake configuration via the VKFFT_BACKEND variable. Consuming C++ projects can simply adjust the variable to match the desired backend on the user's system. However, Python packages must be built and then distributed to users. As VkFFT does not offer dynamic backend selection it is difficult to support runtime backend selection in a single package.

@thewtex Do you have thoughts on the best way to distribute package variants for different backends in PyPI? Is it necessary to publish a differently named package for every backend we wish to support (itk-vkfftbackend-opencl, itk-vkfftbackend-vulkan, itk-vkfftbackend-cuda) or is there a cleaner way to do this?

[Leengit]

From a syntactic perspective ... if we go with differently named packages then rather than itk-vkfftbackend-opencl, etc., I've seen what corresponds to itk-vkfftbackend[opencl,vulkan,cuda] (... or just one such option in the reasonable scenario that we aren't supporting multiple backends simultaneously).

[tbirdso]

Trying to build against CUDA, it looks like our structs are more tightly coupled to OpenCL than I initially realized. itkVkCommon.h and itkVkCommon.cxx both directly use OpenCL enums.

We can probably still mimic the underlying structure of VkFFT.h in using #if(VKFFT_BACKEND==<val>) statements to selectively define structures to match the selected backend.

[tbirdso]

Remaining CUDA task list:

• test on Linux
• Add CI steps for cxx testing (Windows, Linux, macOS)
• Add CI steps for Python testing and packaging (Windows, Linux, macOS)
• Package and distribute on PyPI as itk-vkfftcuda