Support 32-bit floats in reproject_adaptive

[svank]

I'd like to get eyes on this. In the PUNCH pipeline, I'm experimenting with using 32-bit floats to cut our in-memory data volume, and with having reproject put the output bits directly into a slice of a shared-memory array, so I can reproject a stack of images in parallel without having to copy inputs and outputs through pickle/multiprocessing. The latter doesn't seem to need any changes in reproject unless I want that array to be 32-bits.

To add single-precision support to reproject_adaptive, Cython has a floating type, where it generates both single- and double-precision version of the function. All instances of floating must match, though, so we can pass input and output arrays that are both 32-bits or both 64-bits, but not a mixture.

Then it just takes some care to make sure those input and output arrays always have the same dtype, and that that type is acceptable to cython. (If the input array has non-native endianness, that has to be fixed, for example.)

[astrofrog]

Does this change have any impact on what happens if someone calls reproject with an integer array?

[svank]

I think we'll still be good. array_out is either the default of double, or it's a user-provided array. In the latter case, if its dtype is int or otherwise weird, we can't do anything---we can't change or replace the user-provided array, so we'll crash. If array_out has a floating-point dtype, then we cast array_in to match, so that will handle integer array_in. (The first as_array is to make sure it's an array at all, with a .dtype, and the second as_array casts it if necessary. I think I can simplify that though.)

[svank]

I just pushed a commit that avoids the two np.asarray calls and makes the casting a little more clear.