Remove testing of linked libpython - #15

This code works just fine for the most part (the only odd case I have run into is pythonnet/pythonnet#1388, and that is mainly about how dladdr deals with the calling executable, which is not necessarily the same as what the shell thinks). Is there anything particular that you think doesn't work correctly?

I didn't see it work correctly. On Debian with the system Python distribution and Linux conda it returned {cwd}/python, like in the issue you posted, which put the code into "dubious" territory to me. I will admit I didn't try hunting the issue down. After realizing that most Linux's Python configurations were fairly consistent and the code wasn't necessary to find libpython, I decided to remove it. Most Python distributions on Unix-like systems have a statically linked Python executable (for speed and packaging reasons) and this method will rarely return libpython, and we don't want it to return the Python executable.

Is there an environment that is broken without this function? I'd be willing to add it back with your fix if there is.

Well, on Windows it is always the case, and even on Linux people may decide to use this configuration. The way I fixed it (not tested yet) in our vendored copy is to check the sysconfig for Py_ENABLE_SHARED on Unix:

https://github.com/pythonnet/pythonnet/pull/1396/files#diff-b7042a96778615513ad593538de3b95134b5a8be6da827a843a5f00ba9d553ca

Thanks, I'll keep it in mind.