Allow use of faster floating-point number serialization (StreamWriteFeature.USE_FAST_DOUBLE_WRITER)

[pjfanning]

relates to #514

[pjfanning]

@plokhotnyuk I took some of the Ryu tests and used them to test Schubfach and this line 92 is one strange diff - the assert works as "1.0E-44f" in Ryu but I had to hack the value here for Schubfach. Any ideas?

[plokhotnyuk]

Results from Schubfach are rounded with exact precision of 2 decimal digits.

Just see exact representation of the float with significant 7:
https://float.exposed/0x00000007

[pjfanning]

@cowtowncoder the Ryu and Schubfach algorithms don't output exactly the same values as JDK Double.toString - at least for some edge cases and when the values differ, the difference is very small - would there be anyway to have jackson-core NumberOutput support JDK approach as default and to have an option to use Schubfach (which is faster than Ryu) if the user enables a flag?

[cowtowncoder]

@pjfanning I think it is reasonable to have a non-default flag to enable "fast but incorrect" (I think? JDK implementations is, from what I recall, quite precisely compatible well-defined criteria of closest value, round-trupping). As with NumberInput there is the question of how to handle configurability; I'm pretty sure it should default to JDK for legacy cases where boolean setting cannot be passed.

[pjfanning]

@cowtowncoder I'll probably hold back on doing anything with this writer code until the fast double parser work is merged. I think that is getting close enough to something that could be considered for merging.

[cowtowncoder]

Ok I think this can be closed?

[pjfanning]

@cowtowncoder the recent merges affect parsing (and deserialization) - this PR affects serialization - there is still a little bit of work to do on this but it is close enough to being ready

[cowtowncoder]

As with reader side, let's move this to more general StreamWriteFeature as it need not be JSON specific but applicable to most if not all textual format backends.

[cowtowncoder]

@pjfanning d'oh! I really should read the description in detail before commenting something stupid. Yes, that makes sense.
Just let me know when merging would make sense. Could be split in multiple parts too but may not be necessary.

One thing that makes things easier to merge is that 3.0 (master) has immutable factories, so using builders (JsonFactory.builder().... or equivalent from BaseTest) avoids some merging issues. But I can usually handle those quite easily, just cause intermediate merge conflict.

[pjfanning]

@cowtowncoder is this PR now a manageable size? It will have some merge issues in master but shouldn't be too bad.