Formatting double values is not always appropriate

[fkleedorfer]

I have a use case in which high-precision double values are needed. I don't think I can define a DecimalFormat that produces these.

I have been using BigDecimal.toString() to generate the literals, and I don't want the formatter to touch these.

Also, double formatting is the only aspect in which the formatter alters the data. That actually is a big deal, I am not sure it should be enabled by default, as you cannot use automated isomorphicity checks on the result.

[atextor]

Hi @fkleedorfer, I think you are absolutely correct in that the formatter must not alter data. The idea of the number formatter was to have a uniform way to write the numbers. In the first iteration of the feature, you could provide an own lambda function that would write the number as you wish (using DecimalFormat, .toString() or whatever), but you can't easily pass those as a command line option (in owl-cli), which is why I changed it.
Thinking about it, it's probably the best idea to by default print the original lexical form (the solution in your PR), so thank you, I'm all for it.