Added a new fast reading/writing engine to io.ascii

This PR adds a Cython/C parsing engine to the infrastructure of `io.ascii` so that new reading classes for simple formats (currently `FastBasic`, `FastTab`, `FastCsv`, `FastNoHeader`, `FastCommentedHeader`, and `FastRdb`) can opt to use this engine instead of the ordinary `BaseReader` inheritance model. The ordinary readers for these formats still remain to maintain flexibility and compatibility. The PR introduces a new parameter ``use_fast_reader`` in `ascii.read()` which can be used to enable or disable the fast engine (by default, `read()` will attempt to use the fast reader and fall back on the slow reader if parsing fails). The fast readers are also on the guess list directly in front of their slower counterparts.

There is also a Cython engine for writing with these formats; a similar parameter ``use_fast_writer`` can enable or disable this engine, and `ascii.write()` uses the engine by default when writing output in a compatible format.

Using randomly generated text files, it seems that the fast reading engine is anywhere from 3 to 7 times faster than the ordinary readers depending on the data type of table columns, while the fast writing engine is anywhere from ~2.5 to 12 times faster than the ordinary writers; both engines have less of a speed gain for floating-point data, which might be worth looking into at some point. [Here](http://amras1.github.io/astropy-benchmarks/#) are some before and after benchmarks, which cover a range of ASCII formats and compare Astropy's performance with that of numpy and Pandas. There is also a short design document [here](https://github.com/amras1/astropy-benchmarks/blob/master/design.md), which gives a quick overview of the parsing implementation in this PR.

Please feel free to make any suggestions or ask me anything.
First of all, my original "discovery" that limiting `xstrtod()` to 16 digits kept very precise values within 0.5 ULP was a mistake--the conversion simply failed, so `read_csv` treated the value as a string and the error was therefore 0! :laughing: 

I think I have a pretty decent solution now. If the number of significant figures is capped at 17, and decimal values after 17 significant figures are skipped so that the exponent can be read, the problem you discovered should theoretically be fixed. I tried this and found it didn't really work correctly, though, and as it turns out the culprit was the exponent scaling step at the end of `xstrtod()`. The previous method involved repeatedly multiplying or dividing the original integer by powers of 10, but this was problematic because the rounding errors at each step (though guaranteed to be less than 0.5 ULP invidually) often compounded into something fairly large. I found a workaround by simply caching powers of ten beforehand in a double array and either multiplying or dividing the original integer by the index of the absolute value of the exponent in the array. Some [testing](http://nbviewer.ipython.org/github/amras1/ascii-profiling/blob/master/conversion_profile.ipynb) indicates that low-precision values are now guaranteed to be within 0.5 ULP and that high-precision values have about a 90% probability of being within 1 ULP with no linear growth in potential error.