Provide a parse tree view to solve issue #12

Add a `tryParseTree()` method to `Parser`. The code has been tested against a relatively complex project of mine. The result is satisfactory to me. You can review the test cases to see the result.
I indeed thought stack trace was filled lazily and not upon construction.
Did not benchmark though...
Le 22 nov. 2014 17:37, "Winter Young" <notifications@github.com> a écrit :

> In jparsec/src/main/java/org/codehaus/jparsec/Parser.java:
>
> > @@ -552,6 +564,20 @@ public final T parse(CharSequence source, String moduleName) {
> >    }
> >
> >    /**
> > +   * Parses {@code source}. Different from the {@code parse()} counterpart, this method doesn't
> > +   * throw a {@code ParserException} on a failed match, but returns a ParseException that
> > +   * contains the {@code ParserException}.
> > +   *
> > +   * @param source     the source string
> > +   * @param moduleName the name of the module, this name appears in error message
> > +   * @return the result
> > +   * @since 3.0
> > +   */
> > +  public final ParseResult<T> tryParse(CharSequence source, String moduleName) {
>
> oh, i used or() to ignore unrecognized tokens in my last work, didn't
> think it could log failed match. that is interesting. but i do think that
> approach is a little counter-intuitive.
>
> i didn't know exception construction is the most expensive part. so it
> seems this part must be rewritten. however, i leave the choice to you and
> arnaud. if you guys think a new api for non-exception-throwing is good
> enough to have, i will write a new api. if you think it's not worth it, i
> can live with that too. we have or() combinator anyway.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/abailly/jparsec/pull/29/files#r20758177>.
>