FindPython.cmake Gaudi Fix, master branch (2020.01.10.)

This caught me off guard as well...

I didn't realise that the Gaudi build would be exposed to the newly introduced FindPython.cmake module. But it is. (Took me a while to understand how...)

Even though Gaudi only ever calls find_package(PythonInterp) and find_package(PythonLibs), and our FindPythonInterp.cmake and FindPythonLibs.cmake modules explicitly don't use FindPython.cmake from AtlasLCG (I checked, they don't, they directly use FindPython.cmake from CMake.), CMake still remembers that a module named Python was found.

So when Gaudi gets to assembling its environment setup, and starts re-finding all modules that the build uses, it explicitly calls find_package(Python). (Beside find_package(PythonInterp) and find_package(PythonLibs) as well.) So at this point the Gaudi code gets exposed to our newly introduced FindPython.cmake module.

And the build problem appears because Gaudi doesn't know anything about the FORCESET environment setup "command" that we like to use. And so its CMake configuration fails. 😦

Now, since the Gaudi build really doesn't need PYTHONHOME to be set to anything to work, I tried to solve the issue in the simplest way that I could think of. This shall (hopefully) fix athena!29377 (merged).

Pinging @fwinkl.