Correct relative library path

[bgermann]

This fixes the issue introduced in d9be1d8.

[tim-eves]

I'm coming to the conclusion that this is a packaging problem with the wheel and that it should place the built so/dll in next to the init.py. Then the entire block starting if libpath is None could be removed and we can rely on ctypes.util.find_library to locate the so/dll for us.

[bgermann]

ctypes' and ctypes.util.find_library's search paths do not contain the module's path. So even if we moved the library it would still not find it. Please merge.

[bgermann]

It would have been great if you had put this in the 1.3.13 release. Will it be included in the next release?

[bgermann]

@mhosken Can you pleasetake care of this?

[bgermann]

As nobody seems to care about this issue, I will explain it more in-depth. If scikit-build is available at build time the Python module is built with it, which includes building the graphite2 library via cmake. The resulting directory structure does not fit with the search path for the library that is part of the module.

This is not important for systems where graphite2 is installed in the system's library path. But it is very important for other systems, e.g. for Windows. At the moment there is no good user story for people wanting to use the graphite2 Python module on Windows. This also impacts Graide. If there was a wheel on PyPI including the built library the user story would improve a lot. I am willing to publish such wheels on PyPI starting with the next release given that this PR is merged.

[mgood7123]

applied in #69