BUG: simplify void scalar getfield/setfield - #5642

This PR removes most of the logic in voidtype_getfield and voidtype_setfield. Instead they simply call the ndarray getfield and setfield. This solves bugs related to void-scalar assignment

This fixes #3126, #3561. An alternate PR for solving these issues is #4556.

However, this PR introduces a backwards incompatible change, which causes some current scipy tests to fail: Assignment to a void scalar's object array fields now unpacks any arrays on the lhs of the assignment, unlike before (details below). Edit: No longer a problem

In addition, this PR would eliminate potential segfaults involving object arrays if applied in combination with my other PR #5548. This PR currently does not pass numpy tests for this reason, as it exposes a potential bugs that were silent before. Specifically, in this PR, some tests now raise errors of the form "Cannot change data-type for object array" because they attempt to directly modify memory in object arrays. This was previously silently allowed, but now raises an error (which I think is better). My other PR would elimitate the errors. Probably my other PR should be considered before this one is.

More detailed justification for the changes:

Removed byteswapping code

I removed code that does byteswapping in both getfield and setfield. After looking at it for a while, I am convinced this code is unnecessary (though this definitely needs to be checked by others). The reason is that in both cases we use gentype_generic_method to convert the void scalar to a 0-d ndarray, do the get/setfield, and then convert the returned value to a scalar using PyArray_ToScalar (in PyArray_Return). However, note that PyArray_ToScalar already does the byteswap for us. Therefore, any scalars that reach voidtype_getfield are already in NBO and there is no need to swap again.

Change to object array assignment

This PR causes setfield called to behave differently in the specific case where the user tries to set a field of Object dtype, on a void scalar, to a value which is an ndarray. This causes some scipy tests to fail, involving loading matlab save files. The following example demonstrates what is going on:

Setup:

>>> st2 = np.empty((1,1), dtype=[('one', 'O'), ('two', 'O')])
>>> v = np.array([[("ABCD",)]], dtype=[('three', 'O')])

Old Behavior:

>>>#setfield of a void scalar
>>> st2[0,0]['two'] = v
>>> st2
array([[(None, [[('ABCD',)]])]], 
      dtype=[('one', 'O'), ('two', 'O')])
>>> st2[0,0]['two']
array([[('ABCD',)]], 
     dtype=[('three', 'O')])

>>>#setfield of an ndarray
>>> st2['two'] = v
>>> st2[0,0]['two']
('ABCD',)

New Behavior:

>>>#setfield of a void scalar
>>> st2[0,0]['two'] = v
>>> st2
array([[(None, ('ABCD',))]], 
     dtype=[('one', 'O'), ('two', 'O')])
>>> st2[0,0]['two']
('ABCD',)

>>>#setfield of an ndarray
>>> st2['two'] = v
>>> st2[0,0]['two']
('ABCD',)

In the old behavior, setfield on a void scalar on a field of Object type was a special case in numpy code - if the value being assigned was an ndarray it would not be broadcast, unlike all other types of assignment where it would be, and unlike for non-object dtypes. I think there is a case to be made that the new behavior is more consistent - it does not have the (undocumented) 'special case'. On the other hand, this seems to have been the way scipy uses to set an object field with an ndarray as the value without broadcasting the ndarray - scipy code would have to change. It is a bit tricker to do that now - but still possible, eg with st2[0,0] = (None, v).