Set the stream locale to "C" locally

[sbarzowski]

So that even if there is a global locale
set by the library user, Jsonnet output
is still the same.

[sbarzowski]

Fixes #722.

It makes sense to add a regression test and check that we don't have the same problem in other places. Perhaps we can have a helper function to create stringstreams and clear the locale?

[sparkprime]

The test failed on mac gcc. It looked like a legitimate failure with the locale stuff but I didn't understand the error. I ran it again anyway, just in case.

[sparkprime]

Same thing:

terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid

[sparkprime]

My guess would be that it needs some packaged installed to get the right locale files. However I'm not sure why it works on clang but not gcc? Maybe they use different standard libraries and the clang library bundles it.

[sbarzowski]

I tried getting to the bottom of this again, but I'm still very confused. One idea that I haven't checked yet is that the locale is just not there, but clang-compiled-version falls back to something "gracefully" and gcc-compiled-version crashes.

[johnbartholomew]

This still seems worth fixing. std::locale::classic / C locale should always be available I think. We just need the test itself to not rely on a particular locale that might not be available on the system where the test is running.

I've rebased to master and made some adjustments to the test, see master...johnbartholomew:jsonnet:sbarzowski-fix-locale-dependence

[johnbartholomew]

Re: the test failure on Mac (#724 (comment)), it might be this? https://stackoverflow.com/a/58385001

Anyway, I think it can/should be avoided by just defining a custom locale facet for the test.

[johnbartholomew]

As this PR has been open for a long time (4+ years), I'll just go ahead and rebase and merge this (with a few adjustments/additions)