Re-use already existing functionality to determine the library path according to the shared library.

[arizvisa]

Hi there. I'm not sure if this PR will interest you guys, especially because it's windows-specific. On my system, I have multiple versions of Python (due to embedding) and with my recent transition to Tauthon this includes yet another. This PR allows the interpreter to locate its PYTHONHOME by getting the path of its shared object (DLL) when it's unable to depend on the registry, or environment variables. Similar to the original implementation, the registry and environment variables will still get priority, just when there is nothing defined or available the DLL path will be used.

Details:
Anyways on the Windows platform, Python 2.x has implemented a couple of hacks in order to locate the base python directory which contains all of the libraries that are searched. On these platforms, you'll typically use PYTHONHOME, PYTHONPATH, etc. to inform PC/getpathp.c where to search. The method that is actually used (due to the installer), though, is an option in the registry at Software\Python\PythonCore.

However, to assist with applications embedding the library, the default Python installer literally drops the Python27 DLL into the System32 directory. This unfortunately prevents more than one instance of the language to be installed since it is installed globally (overwritten) and unversioned. This was done to guarantee that the DLL is in the library search path so that LoadLibrary will always see it. In all actuality, the library can be included in the PATH variable which the installer does anyways.

To workaround this limitation, things like virtualenv include an "activation" script that explicitly sets these environment variables and makes a copy of the executable and DLL in the same directory since the platform will give priority to the current directory. This patch allows one to simply make a copy of their Python directory to get the same effects as virtualenv.

Fix:
So to deal with this, it turns out that PC/getpathp.c actually had already attempted to accomplish this but over time was broken. I simply re-enabled it by copying the dllpath into pythonhome, and re-organized it so that it's only used as a fallback if nothing else works (giving priority to registry and environment).

[arizvisa]

If there's interest in these types of fixes such as building for later versions of VS as described in #46, or updating the installer (in order to simplify access for more users). I don't mind contributing towards them since my primary Python platform is Windows and Python2/Tauthon. Lmk if that's the case.

[stefantalpalaru]

Thanks! I made this small modification: 03cdf76

Yes, we're interested in these Windows-specific fixes.

[arizvisa]

Cool. I'll include a few more in the future then.