Remove PyArrayModule

[kngwyu]

and use static variable to access Numpy C APIs.
Since nowt we can't ensure operation's safety by PyArrayModule's lifetime, I changed all APIs to return or take &'py PyArray.
TODO:

• comments
• notes on README, that indicates really breaking change has done

[termoshtt]

Great work 👍
This matches the PyO3 way well.

[termoshtt]

Do you have any plan to fix it?
I try to use lazy_static and Mutex, but it (9bd4376) does not work :<

[kngwyu]

Somewhat calling python ffi from a synchronized path causes dead lock when cargo test executes multiple tests in parallel.
But I think we can ensure safety of substitution to ARRAY_API_CACHE by std::sync::Once

[kngwyu]

i.e.
This is OK

let api = get_numpy_api(MOD_NAME, CAPSULE_NAME);
INIT_API.call_once(move || {
    ARRAY_API_CACHE = PyArrayAPI_Inner(api);
});

but this causes dead lock, in parallel tests

INIT_API.call_once(move || {
    let api = get_numpy_api(MOD_NAME, CAPSULE_NAME);
    ARRAY_API_CACHE = PyArrayAPI_Inner(api);
});

[kngwyu]

And I think we don't have to use Mutex.
We have to lock the access to Numpy API only once in a program, since Numpy API is pinned by capsule.

[termoshtt]

It seems to be correct.

[kngwyu]

Thanks for review, I synchronized the substitution to static.
But, still python ffis can be called from multi threads(though they have their own lock, I think).

[termoshtt]

But, still python ffis can be called from multi threads(though they have their own lock, I think)

The parallel test by cargo test calls APIs in parallel, but it does not cause any problem. GIL works fine for this.

[termoshtt]

LGTM