Basic benchmark framework
Implement string parsing benchmark
Added printing benchmark
Tidy code and output
Added Caliper based testing
\, is a legal character literal
add ABenchmark to support benchmarking parsing

Concrete parsing benchmarks will extend this.
add test data for performance benchmarks
Add Caliper benchmarks using previously added data

CombinedBenchmark: parses all the input data to produce an aggregated
performance result.

IndividualBenchmark: produces benchmark results for each data file
individually, but requires more time.
\, is a legal character literal
Merge branch 'topic/performance-test'

* topic/performance-test:
  \, is a legal character literal
  Add Caliper benchmarks using previously added data
  add test data for performance benchmarks
  add ABenchmark to support benchmarking parsing
  Added Caliper based testing
  Tidy code and output
  Added printing benchmark
  Implement string parsing benchmark
  Basic benchmark framework
  make Scanner faster by caching current char
ParserImpl free of mutable state, except for Scanner

Scanner could be threaded through all calls as a parameter instead of
being part of the state of the Parser, but I'm not seeing what
advantage that would bring: Parsing is inherently stateful at some level
since the source of characters is stateful in the sense that we want to
read each character exactly once and in the correct order.

Currently parsing is implemented in three layers:

- Parser
- Scanner
- Readable

Conceptually, we can divide it even more finely:

5. Parser (source of Values)
4. Scanner (source of Tokens)
3. Buffered Source of Characters granting lookahead of 1
2. Source of Characters
1. Readable

(1) is inherently stateful. (2) is inherently stateful, transitively.
(3) is inherently stateful because the last character looked at by
    one call to the scanner, might need to be looked at first by
    the next call to the scanner.
(4) needs (3), so 4 is stateful.
(5) is stateful because it uses (4).

Now, we could break this transitive chain of statefulness at any point,
by incorporating more input parameters into the methods to be called
and/or returning more complex return values. The scanner could return
the recognized token, and the state necessary for the next call. But
this is no solution. This doesn't solve the state problem, it just makes
it someone else's problem.

The fact is there's nothing to be gained by making the scanner or the
parser "thread-safe". They are performing an inherently serial task
across a single source of input. They are designed to be light-weight
single-use objects, much like the Readable they are ultimately built
upon. If you want to parse from multiple input streams concurrently,
use multiple Parsers. It's not like they are expensive to create or
to dispose of.
first step toward building Scanner on a PushbackReader

The hope is that, like clojure, I'll be able to confine the mutable
state of the Parse to the PushbackReader.

That's going to mean threading curr as a parameter through all
methods. To go really stateless, I'll have to thread pbr through as
well. I'll also have to deal with the fact that you can't unread
the end-of-stream marker.  Maybe this won't be such a problem; the
documentation of Reader.read() leaves open the possibility of calling
read() as often as you like past the end of the stream (and just
getting -1 back every time.)
Confine mutable state in Parser+Scanner to just the PushbackReader

The next step is to remove mutable state entirely from Scanner by
passing it in as an argument when calling Parser.nextValue() and
Scanner.nextToken().
remove mutable state from Parser+Scanner

This implies that Parser.nextValue(…) now takes a PushbackReader, which
it necessarily mutates, as an argument.

The upside is that Parser (and Scanner) are now immutable and thread-
safe.

The downside is that the user of a Parser now must keep track of two
objects: the Parser and the PushbackReader.

Internally, Scanner and Parser appear more complex because they are
threading up the method call chain all the state that they used to
simply contain.

I'm not yet convinced that this is such a win.
instead of passing cure and pbr, arrange for pbr to begin with curr

This means that our PushbackReaders will need to be able to push
back (at least) 2 characters.
inline parseFloat, parseInteger to remove a little pbr juggling
eliminate need for pushback > 1, by selectively reintroducing curr

readSymbol and readNumber gain an overload taking the as their first
argument the character which logically precedes the contents of pbr.
This eliminates the need to push back 2 characters when we disambiguate
between negative numbers and symbols that begin with '-'.
small refactorings in scanner
define Parseable to take the place of PushbackReader in our API

Parseable only provides a single character of pushback, but that's
all we need. It seems considerably faster than PushbackReader for
our purposes. (At least when parsing strings from memory.)