Added support for additional data types for rasterize function

This resolves #136 by adding support for additional data types to rasterize. This includes additional dtype parameter to features.py::rasterize(), and one API change to the value of the default_value parameter (from 255 to 1).

This was aided by adding a utility class InMemoryRaster for use in cython to handle IO between 2D numpy arrays and GDAL raster bands used by the GDAL functions. This has broader applicability than just this issue; it will likely aid #138 and others.

This PR also includes io_auto in _io.pyx, which simplifies routing to the appropriate IO function for reading / writing between numpy arrays and GDAL raster bands, by routing to the appropriate function based on the dtype of the numpy array.

Validation logic inside features.py::rasterize() had to be completely rewritten to catch data type conflicts.

This also includes new test cases to make sure that the additional data types are handled correctly by rasterize, and some cleanup of the existing rasterize tests (including a bit of PEP8 conformance).