BUG: float conversion in read_csv is inaccurate for precise input
This is coming from #2566, which noted that the `xstrtod()` method used by `read_csv` doesn't agree with standard numpy float conversion. I see that the priority is speed of parsing over complete accuracy (within 0.5 units in the last place, or ULP), but there are two issues here that (at least to me) actually appear to be buggy:
1. Low-precision values (i.e. less than about 15 significant figures) should be guaranteed to be within 0.5 ULP of the correct result, or at least within 1 ULP. However, I have found cases in which `xstrtod()` is off by _more_ than 1 ULP, although these don't come up often.
2. High-precision values of course can't be guaranteed to be within 0.5 ULP without a costly correction loop as in the ordinary `strtod()`, but the error in conversion increases linearly as the number of supplied significant figures increases. With 30 significant figures, the error in conversion can potentially be over 7 ULP.

[Here](http://nbviewer.ipython.org/github/amras1/ascii-profiling/blob/master/fast_conversion_profile.ipynb) is an IPython notebook analyzing the accuracy of `xstrtod()`. I think there are two problems here: `xstrtod()` keeps reading digits after the 17th, none of which should matter for conversion, and the scaling step at the end produces a compounded error by repeatedly multiplying/dividing by powers of 10. I have a solution for AstroPy that seems to fix these issues, so I can open a PR if it's agreed that `xstrtod()` should be changed.
