Improve perf of float and double parsing in TextBuffer

[pjfanning]

• just an outline - not for merging
• relates to Add char[] versions for NumberInput parseFloat, parseDouble, parseBigInteger #1229
• In TextBuffer, when parsing floats and doubles, avoid creating Strings first
• copies the logic of contentsAsString into the float and double methods so that we can best handle the various scenarios
  • if _resultString already exists, use it
  • if _resultArray already exists, parse from the array instead of creating a String
  • in the case that multiple segments are needed, we might as well fall back to contentsAsString in this case because we need to build a String with a StringBuilder anyway

@cowtowncoder is this a long the right lines? If so, I can add tests. If we get this done for floats and doubles, we can come back to make similar changes for other number types.

I'm aware that this does not address the deferred number parsing in ParserBase (where numbers can be stored as _numberString until we know what type we need). Storing the number as the wrong number type and later converting it to a different number type can lead to number conversion issues and can be more expensive.

[cowtowncoder]

@pjfanning Yes, this is what I had in mind. I'll have a look and suggest some changes. Since we are not (yet) changing calling from ParserBase, I think this could actually go in 2.17, even.

I also think that we can remove some of deferral because calls to, say, getFloatValue() does explicitly establish target type -- but this is easy enough to verify with more time wrt 2.18 once 2.17 is out.
But that question is separate from work to make TextBuffer pass more optimal representation.

[cowtowncoder]

I think I'll go ahead and merge this: it will be needed to tackle #1229.

[cowtowncoder]

This was a bug, actually -- should use _hasSegments instead! Fixed in #1313.

[cowtowncoder]

Same here, fixed in #1313