[fftw3] Cleanup of CMake targets. Modernize. Improve DLL marking.

[ras0219-msft]

Improves handling of DLLs/static libraries by directly encoding the setting for FFTW_DLL in the headers.

May fix #6434 (comment) -- @alessandroarduino, could you confirm?

[alessandroarduino]

No, it is still not working for me. The linker gives the same error LNK2019 as before.
Things seem to work properly if I comment out line 3 of file portfile.cmake.

I cannot understand very well what is going on in portfile.cmake, so I ask: does the function call vcpkg_check_linkage(ONLY_STATIC_LIBRARY) make superfluous the check if(VCPKG_LIBRARY_LINKAGE STREQUAL "static") at line 99? Or is it actually possible to make the library dinamic? Maybe the problem lies here, doesn't it?

Thank you very much for the extremely fast reply!

[Neumann-A]

Things seem to work properly if I comment out line 3 of file portfile.cmake.

seems more like @ras0219-msft just forgot to remove that line in the PR

[ras0219-msft]

Ok, after further investigation I figured out the issue.

When building shared libraries, FFTW doesn't export certain internal symbols that are required by its separate threading library. Fortunately, there is an option WITH_COMBINED_THREADS to build these both into a single shared library so this is no longer a problem :).

This should re-enable FFTW building as shared libraries AND fix the issues with the threads subcomponent.

[ras0219-msft]

/azp run