Python3 fixes (maintains python2 compatibility)

[temetski]

After some digging, I think I may have resolved the segfault issue on Python>3.6.1 on MacOS (see #179). It has to do with

1. Linking of necessary python libraries to swig
2. Deprecated swig_link_libraries (see https://cmake.org/cmake/help/latest/module/UseSWIG.html in conjunction with https://cmake.org/cmake/help/latest/policy/CMP0078.html)
3. Deprecated PythonInterp and PythonLibs. Best way to pass libraries to target_link_libraries is using Python::Module of FindPython

This PR changes PythonInterp and PythonLibs to prefer FindPython, which detects your python library (python 2 or 3) and sets up CMAKE appropriately. It then deprecates swig_link_libraries in favor of target_link_libraries for CMAKE versions 3.13 and above.
Additionally, assuming the presence of conda indicates preference for the python conda version, added

fmm/CMakeLists.txt

Line 39 in 676ced5

set(Python_FIND_STRATEGY LOCATION) # might want to prefer conda over system python

following suggestions in https://gitlab.kitware.com/cmake/cmake/-/issues/21322. This addresses issues when conda's python version is less than that of the system python install.

The above changes seem to still be compatible with ubuntu-based python 2 and python 3 installs, while resolving the segfault issues encountered in the python3 install of fmm on MacOS.

CI testing might have to be changed a bit to test for python3 since python defaults to the python 2 install in most systems.

Edit: It seems most of your build configs for testing rely on ubuntu 16.04, which uses an old version of CMAKE. To maintain compatibility with the old and new CMAKE versions, we can use PythonInterp and PythonLibs for CMAKE<3.13, while using FindPython for newer CMAKE versions.

[cyang-kth]

Thanks for your contribution. I will have a look at my spare time.

[Ianc98]

Some methods need replacing too, such as'has_key'

[rderollepot]

Thank you for this PR, helped a lot!

[AlessandroGianfelici]

makes the example work with python 3.x without breaking the compatibility with python 2.x. It's a small fix that could be merged

[AlessandroGianfelici]

everithing works with python 2.x and 3.x