Additional data type support for rasterize

This resolves Issue 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 Issue 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).