Add SimpleStreamReader

[jhy]

Continuing on the work in #2186 to reuse large buffers to minimize allocations (and therefore GC) during parsing, this change allows us to reuse the byte -> char decoding buffer.

Replaces uses of InputStreamReader with a simplified version, where we recycle the underlying byte buffer, vs creating a new 8k buffer on every parse.

Gives a good performance improvements for all but the largest inputs, where the allocation cost is amortized across a longer parse.

[jhy]

Benchmark results of before and after. These parse from an InputStream; that's the path impacted by this change. We use this for HTTP and File inputs.

Using InputStreamReader:

Benchmark                               Mode  Cnt       Score        Error  Units
ParseFromInputStream.parseLargeInput   thrpt    6    1176.463 ±    522.520  ops/s
ParseFromInputStream.parseMediumInput  thrpt    6   49681.672 ±    646.623  ops/s
ParseFromInputStream.parseSmallInput   thrpt    6  156302.842 ±   1348.830  ops/s
ParseFromInputStream.parseTinyInput    thrpt    6  867574.078 ± 153288.428  ops/s

--- 

Recycle input buffer:

Benchmark                               Mode  Cnt        Score       Error  Units
ParseFromInputStream.parseLargeInput   thrpt    6     1347.755 ±    22.431  ops/s
ParseFromInputStream.parseMediumInput  thrpt    6    67034.703 ±   465.228  ops/s
ParseFromInputStream.parseSmallInput   thrpt    6   159489.558 ±   765.581  ops/s
ParseFromInputStream.parseTinyInput    thrpt    6  1069228.282 ± 16183.769  ops/s

[jhy]

Here's a chart of the impact. The specific ops/s change is quite dependent on active memory pressure. Interesting to see that the small size shows little impact relative to the others. Not sure if that's a measurement anomaly of the test or if there's further ground to be made particularly around that size.