npe_matches changes storage order

[alecjacobson]

This is a minimal reproducible example of a problem identified in the libigl python bindings

Please see https://github.com/alecjacobson/numpyeigen-example-project/tree/alecjacobson/buggy-npe-matches

git clone -b alecjacobson/buggy-npe-matches git@github.com:alecjacobson/numpyeigen-example-project
cd numpyeigen-example-project
python setup.py develop
python tests/test_example.py

This will print

B_python:
 [[0. 1. 2.]
 [3. 4. 5.]]
B_cpp:
0 2 4
1 3 5

Which shows that the matrix B is having it's data order mangled when converted to an eigen object.

I think something is going wrong when using

npe_arg(A_cpp, dense_float, dense_double)
npe_arg(B_cpp, npe_matches(A_cpp))

In python A is a vector but B is a matrix. From the numpyeigen callers point of view, they might have thought that npe_arg(B_cpp, npe_matches(A_cpp)) would have just made sure B_cpp has the same scalar type as A_cpp. Certainly it's unexpected that this compiles/runs but with rerarranged data in B.