WIP: initial reprojection routine

To-do:

* [x] fix 1-pixel offset in output
* [x] make code robust to direction of longitudes/latitude (clockwise, anticlockwise), need to test with various CDELT signs
* [ ] re-write in Cython/optimize
* [x] add tests
* [ ] add flux mode in addition to surface brightness mode
* [x] properly support different coordinate systems
* [ ] for larger images, may not be efficient to convert all the world and pixel coordinates in one go (thought whenever possible, it should be done). One needs 1Gb to store the position of all the corners for a 33Mpix image, which would a little more than an 4096x4096 image. In many cases, it is likely that the output image will be quite large and may go beyond those limits. We could switch to a model like Montage where we proceed row by row or chunk by chunk (row by row may not be the most efficient). If both the input and the output are large, we won't be able to avoid being inefficient and recomputing the same coordinates multiple times if they can't be stored.
* [ ] for large output images, use memory mapping

But to first order, it does appear to be doing the right thing (apart from the 1-pixel offset)


@cdeil - I agree, though on the other hand it depends what we want to expose to users by default. See https://github.com/astrofrog/reproject/pull/35 for an example of high-level API. If this is the main API we want to encourage users to use, we might not need to expose the other functions at the top-level. Certainly for the ``wcs_utils`` and ``array_utils`` those are only meant for internal use so should not be imported into the top-level.