Possible memory overwrite in copy_and_swap

In ctors.c (copy_and_swap) it is possible for memory to be trashed by the call to byte_swap_vector if the strided memcpy is performed, because d1 points to the end of the buffer after the copy. We don't see this happening in the wild because this function is only currently called with numitems == 1 or itemsize == srcstrides, so the first IF-statement path is always taken. Still, I think it should be fixed in case this ever changes.

The fix is to make sure we always pass dst to the byte_swap_vector function and move the d1/s1 variables local to the stride copy. This way they cannot be inadvertently used later on. In fact this bit of the code could probably be replaced by a call to _unaligned_strided_byte_copy in future.

Since it's not possible to get the Python to cause this code path to run, testing was performed by temporarily commenting out the first memcpy path and always choosing the strided copy (which also works for the simple case). For the existing code, after running the 'core' tests, the python interpreter segv'd on exit. With the fix, the tests complete successfully without adverse effects on the interpreter.