Move _pygit2 to pygit2._pygit2

[rcoup]

This resolve issues with binary top-level modules affecting delocate on macOS (which helps with macOS wheel creation). Specifically, matthew-brett/delocate#12 (comment)

Change is that it moves (eg) site-packages/_pygit2.cpython-37m-darwin.so to site-packages/pygit2/_pygit2.cpython-37m-darwin.so, meaning the _pygit2 internal api is available via import pygit2._pygit2 cf import _pygit2

The impact this has building macOS wheels:
(fyi delocate-listdeps shows the libraries and what depends on them indented)

Before:

$ delocate-listdeps -d dist/pygit2-1.0.3-cp37-cp37m-macosx_10_15_x86_64.whl
/Users/rcoup/code/pygit2/venv/lib/libgit2.0.99.0.dylib:
    _pygit2.cpython-37m-darwin.so
    pygit2/_libgit2.abi3.so
$ delocate-wheel dist/pygit2-1.0.3-cp37-cp37m-macosx_10_15_x86_64.whl
$ delocate-listdeps -d dist/pygit2-1.0.3-cp37-cp37m-macosx_10_15_x86_64.whl
/Users/rcoup/code/pygit2/venv/lib/libgit2.0.99.0.dylib:
    _pygit2.cpython-37m-darwin.so
@loader_path/.dylibs/libgit2.0.99.0.dylib:
    pygit2/_libgit2.abi3.so
$ zipinfo -1 dist/*.whl | grep -P "\.dylib|\.so"
_pygit2.cpython-37m-darwin.so
pygit2/_libgit2.abi3.so
pygit2/.dylibs/libgit2.0.99.0.dylib

• libgit2 gets bundled into the wheel but _pygit2.*.so is still referencing the $LIBGIT2 path (everything should be prefixed @loader_path/.dylibs/)
• if you actually install this wheel with $LIBGIT2/lib/libgit2.dylib in position too (eg via: import pygit2; pygit2.config.Config()), then you get a segfault
• cause of that seems to be that we end up loading libgit2 twice, once the copy baked into the wheel, and once from the original $LIBGIT2/lib location.

$ python
>>> import pygit2
>>> import os; os.getpid()

$ lsof -p 21632 | grep -P "libgit2\..*\.dylib"
Python  21632 rcoup  txt    REG    1,4   1004300          8737655297 /Users/rcoup/code/pygit2/venv/lib/libgit2.0.99.0.dylib
Python  21632 rcoup  txt    REG    1,4   1004300          8737685087 /Users/rcoup/code/pygit2/venv/lib/python3.7/site-packages/pygit2/.dylibs/libgit2.0.99.0.dylib

By moving the _pygit2 module into the top-level python package, delocate correctly links it to the baked libgit2.

After:

$ delocate-listdeps -d dist/pygit2-1.0.3-cp37-cp37m-macosx_10_15_x86_64.whl
/Users/rcoup/code/pygit2/venv/lib/libgit2.0.99.0.dylib:
    pygit2/_pygit2.cpython-37m-darwin.so
    pygit2/_libgit2.abi3.so
$ delocate-wheel dist/pygit2-1.0.3-cp37-cp37m-macosx_10_15_x86_64.whl
$ delocate-listdeps -d dist/pygit2-1.0.3-cp37-cp37m-macosx_10_15_x86_64.whl
@loader_path/.dylibs/libgit2.0.99.0.dylib:
    pygit2/_pygit2.cpython-37m-darwin.so
    pygit2/_libgit2.abi3.so
$ zipinfo -1 dist/*.whl | grep -P "\.dylib|\.so"
pygit2/_libgit2.abi3.so
pygit2/_pygit2.cpython-37m-darwin.so
pygit2/.dylibs/libgit2.0.99.0.dylib

Delocate could fix the issue, but the comments in that ticket imply there are additional concerns there, and I can't see any particular need for the internal _pygit2 to be a top-level package.

[rcoup]

Looks like windows builds need some setup.py tweaking to match

[jdavid]

LGTM, but AppVeyor must be green to merge.