Add a mechanism to report syntax errors without exceptions

[Code-Grump]

🤔 What's the problem you're trying to solve?

In the Reqnroll project https://github.com/reqnroll, I am implementing a Roslyn-based source generator. As this runs as part of the IDE as the user is typing, it's important to keep performance in mind. As such, we'd like to avoid exception-throwing as a mechanism for reporting problems in user syntax, as these will occur frequently as the user authors their feature files.

✨ What's your proposed solution?

I would like a method added to Parser<T> which can return either a successful parse result or a failure.

A "try" method would be adequate:

public bool TryParse(ITokenScanner tokenScanner, out T result, out List<ParserException> errors)
{
    ...
}

Alternatively, some kind of "result" type could be used to represent success or failure.

⛏ Have you considered any alternatives or workarounds?

I could not see any other operations exposed by the parser that would support this exception-free model.

📚 Any additional context?

No response

[mpkorstanje]

@gasparnagy you're more familiar with .Net and Berp, what are the possibilities here?

[gasparnagy]

This would not be impossible (at least in the .NET version), because the parser anyway collects the errors in a collection and only throws an exception at the end of the parsing, or when >10 errors collected.

So we would only need to change the template so that these parts are "protected virtual" so that custom parsers can override the behavior and choose to handle the errors differently.

@Code-Grump Let's keep this improvement in mind as a perf improvement, but let's not prioritize it now (or at least I cannot promise to get this done very quickly). In Visual Studio we also parse the feature files for every keystroke and the perf hit is not that significant. We use a parser wrapper there: https://github.com/reqnroll/Reqnroll.VisualStudio/blob/main/Reqnroll.VisualStudio/Editor/Services/Parser/DeveroomGherkinParser.cs (But of course this might be still necessary for the source generator.)

[mpkorstanje]

Okay. That would be useful to keep in mind with #153 too.