Fix mismatched integer sizes in compressionmodule.c on 32-bit

[mdboom]

On 32-bit plaftorms, including Travis, we get this compiler warning.

astropy/io/fits/src/compressionmodule.c: In function ‘compression_compress_hdu’:
astropy/io/fits/src/compressionmodule.c:829:9: warning: passing argument 3 of ‘(struct PyObject * (*)(struct PyTypeObject *, int,  npy_intp *, int,  npy_intp *, void *, int,  int,  struct PyObject *)
)*(PyArray_API + 372u)’ from incompatible pointer type [enabled by default]
astropy/io/fits/src/compressionmodule.c:829:9: note: expected ‘npy_intp *’ but argument is of type ‘long int *’
astropy/io/fits/src/compressionmodule.c: In function ‘compression_decompress_hdu’:
astropy/io/fits/src/compressionmodule.c:906:5: warning: passing argument 3 of ‘(struct PyObject * (*)(struct PyTypeObject *, int,  npy_intp *, int,  npy_intp *, void *, int,  int,  struct PyObject *)
)*(PyArray_API + 372u)’ from incompatible pointer type [enabled by default]
astropy/io/fits/src/compressionmodule.c:906:5: note: expected ‘npy_intp *’ but argument is of type ‘long int *’

Particular when passing the list of dimensions, this could result in the very wrong array size being created.

This uses npy_intp instead of long so the array sizes match on 32-bit and 64-bit.

This may or may not be the cause of the segfaults on Travis, but either way we should probably fix this.

[embray]

Weird. I wonder if this is related to #632, which was also on 32-bit Ubuntu, but that I was never able to reproduce on my own...

[embray]

Also this will need to be backported to pyfits.

[mdboom]

This doesn't fix the Travis builds, but seems like a good idea nonetheless.

[eteq]

This should also be in 0.2, right?

[embray]

I don't know that it needs to be...it's causing any problems that we know of.

[embray]

Manually merged in 97d0197.

[embray]

I wonder if this is what was causing #632...