Fix missing __file__ attribute on builtin modules by applying PythonPath as appending to sys.path

[minesworld]

This time it should work...

• added test for __file__ and __name__ attribute on os module (first commit, so TestHasAttrFile should fail without the patch)

The patch:

• removed Py_SetPath usage and DLL definitions
• added a AppendMissingPathsToSysPath() to CPythonAPI, called within GIL before initializing the types
• AppendMissingPathsToSysPath does as it says: it checks if a path is already in sys.path, if not it will be appended
• PythonPath is splitted "as is", its up to the setter of CPythonAPI.PythonPath to provide absolute paths

AppendMissingPathsToSysPath is written using "raw" nint C-API calls. Added the missing DLL calls as xxxRaw() .

[minesworld]

@tony : my first pull request failed to work as it was based on the wrong fork. The first thing I did was refactoring the CAPI...

PyList_GetItem
PyList_GetItem_

and an (now) an additional

PyList_GetItemRaw

Sorry - but WTF ?!?

My "minesworld" fork which refactors the raw calls into an "Unmanaged" nint based CAPI which is the base for the normal IntPtr CAPI is much "cleaner"... https://github.com/minesworld/CSnakes/tree/minesworld

But the real beauty is the kind of genious NewReference / BorrowedReference C# language usage of pythonnet. Was really astonished seeing that...

The code is the documentation implemented in a perfect way for CPythons C-API. (Somehow ironic looking at the CPython C-API naming)

The only downside to that might be that there is no raw nint and such it might have effects on the heap/stack and is a bit slower...

PS: is there a way in C# to alias a type definition in a way that it is its own type and must be "forced" back if used as its original definition? Like

using pyoPtr = nint;

and passig a pyoPtr x to a function which accepts a nint arg would fail without (nint)x ??