Handle interleaved calls to step, match and result in the java PrettyFormatter

The java PrettyFormatter has relied on that the call to step() for all the steps in a scenario, come before any call to match() for any step in the scenario. When the call to formatter.step() in cucumber.runtime.model.StepContainer was moved from the format() method to runStep() method in the commit https://github.com/cucumber/cucumber-jvm/commit/4fba53c89f206363004fb81893606f9bd7695c2f this assumption is not true anymore. Therefore IndexOutOfBoundsException is thrown from the PrettyFormatter in Cucumber-JVM version 1.1.3 on the second step of any scenario. This has been noted several times, for instance in https://github.com/cucumber/gherkin/pull/252 and https://github.com/cucumber/cucumber-jvm/issues/491, but proposed solutions have masked the problem rather than adapting to the root cause of the problem.

To solve the root cause of the exception, the java PrettyFormatter in this pull request is changed to handle the interleaved sequence of calls to step(), match() and result() that Cucumber-JVM version 1.1.3 is issuing. The solution in the java PrettyFormatter is to also store the received match and result data in a list until the end of the scenario. Then the indentations for the step definition locations are calculated, and the whole scenario is printed at once.

The final formatted result is not changed, but for long running scenarios the delay of printing until the end of the scenario will be notable. Since the printing is delayed until the end of the scenario, the printing of the current step as executing is also removed. This has the side effect that most of the ANSI up cursor magic mentioned in https://github.com/cucumber/gherkin/issues/187 is removed.

Note, for this pull request the java code has been tested through mvn install in the java directory, with the test passed. Other tests, for instance through rake, have not been performed.