GCC/clang floating point parsing bug in strtod()

[twelsby]

I have managed to identify the source of the failure to parse the following number:

1.00000000000000011102230246251565404236316680908203126

which should parse to:

1.00000000000000022

However under gcc/clang on Travis only it instead parsed as exactly 1. Local gcc/clang builds and AppVeyor builds all ran correctly.

This was mentioned in issue #186 where I speculated that it was likely caused by a bug in strtod() in what must have been an older version on Travis. To address that issue and get the rest of the tests to run on Travis, pull #191 (now merged) disabled this test for gcc/clang.

Research identified the following blog post: How strtod() Works (and Sometimes Doesn’t), which indicates that it was caused by the double rounding error that was suspected all along to have caused it. Although the bug was fixed back in 2013, it appears that the bug is still present in both gcc and clang on the version of Ubuntu on which the Travis builds run (precise).

Travis also has a more recent version of Ubuntu (trusty), which is currently in beta. I decided see if upgrading .travis.yml to build on trusty instead might address the bug and allow the test to also be done under gcc/clang - it works. The trusty environment is beta but there do not appear to be any issues with the build and it is inevitable that we will need to migrate to trusty eventually so it might as well be now.

[nlohmann]

Fixed by merging #196.