Faster Parser

[srhickma]

Investigate where slow-ups occur in the Earley parser, if optimations cannot be made, look for a faster parser.

[srhickma]

After #21, the Earley parser's parse tree generation is much more performant, and after #20, the recognition phase should run optimally for all grammars.

[srhickma]

Currently, parse tree construction appears to run linearly or better in the length of the input, whereas recognition appears to run in quadratic time.

[srhickma]

https://drive.google.com/file/d/0B9_mR_M2zOc4SjctSE1kTXpVMkE/view

[srhickma]

Leo parsing modification https://www.sciencedirect.com/science/article/pii/030439759190180A. Try this before looking at the full MARPA implementation above. It is probably worth looking at an online algorithm for chunked parse tree generation and formatting before making the switch to one of these parsers.

[srhickma]

Building the project with the --release flag saw a substantial increase in performance. Duration of the java8 formatter tests went from an average of 6550 ms using cargo build to an average of 250 ms using cargo build --release. With such a large increase in performance here, the formatter is performant enough for real-world usage to be possible, and this issue should be closed. Further optimizations should be made down the line (especially wrt right recursion), but for the time being performance is no longer a blocker.

[srhickma]

At the time of writing, the entirety of the Spring Framework (~7000 files and ~1,300,000 lines) can be formatted in just over 51 seconds.