This PR Introduces a wrapper parseInternals intended to make creating parsingContexts in the various parsing methods of OLParser easier and some prerequisites for it in the Scanner and Parser.

The wrapper is then used to create the ParsingContexts in _parseExecutionInfo(), and parseEmbeddedServiceNode()

This PR is similar to #581, for which @fmontesi, suggested I start with a simpler parsing method like _parseExecutionInfo

The wrapper method <I> InternalParseResult<I> parseInternals(ParsingLambda<I> internalsParser)
has <I>, a type that holds the information required to create an AST node,
the ParsingLambda<I> is identical to a standard library Supplier (supplying <I>) except it throws relevant parser Exceptions.
the return type InternalParseResult<I>, is a record class consisting of <I> and ``ParsingContext`.

The general way the wrapper is used for a parsing method is as follows:

1. Look at the parameters of the constructor for the AST node the method creates. e.g.new Foo(A a, B, b, C c, ParsingContext context)`
2. define a record class containing each parameter A, B, C (but not ParsingContext), if there is only one parameter other than context, you can skip this step.
3. call parseInternals with ParsingLambda a lambda function of the body of the parsing method up to and excluding the point where the AST node is created, at the bottom of the lambda return an instance of the record from 2).
4. Use the InternalParseResult returned by 3) to create the AST node, it will contain the record class of parameter required to do so, as well as an automatically generated ParsingContext.

For examples of usage see the simple parsing method _parseExecutionInfo(), and parseEmbeddedServiceNode() (a slightly less trivial case as requested by @kicito )

Changes I made in Scanner:

• Change currColumn to not increment multiple times on '\t' characters, as it made it hard use with for example LSP Range which does not treat '\t' different from other characters. Additionally I made it 0-indexed to match the LSP Location.character after discussion with (@kicito).
• Fixed how errorColumn is calculated, as it was incorrect for tokens spanning multiple lines (like strings can) or if the token was followed by a '\n'.
• I added 2 ints for tracking the end of Tokens

   private int tokenEndLine;	// Line the last returned token ended on
   private int tokenEndColumn;	// Column the last returned token ended on

In AbstractParser I added required functionality to store and get the Scanner tokenEndLine and tokenEndOffset (together known as TokenEnd) as they were one token ago, this is because some (all?) parsing methods in OLParser by increment the Token stored in the Parser after parsing what they need, and have to work that way e.g.

from .A import B

The import statement may be done here, but the parser cannot know that without reading the next token, as it may be a comma followed by another symbol to import in the same import statement:

from .A import B, C

But that means that the current token of the parser after running a parsing method, will be the next non-newline token (the parser skips newlines).

from .A import B

type t = int //after parsing the import, the parser token will be "type"

Thus the need for storing the TokenEnd for the previous token (B in the example above). It is achieved by storing the last two TokenEnds in a new Deque field previousTokenEnd that is managed by a new method AbstractParser::saveTokenEnd()
saveTokenEnd() is called in AbstractParser::readToken() iff the token read from the scanner is not a newline, this is because AbstractParser::nextToken() immediately calls readToken again if it encounters a newline, which would otherwise overwrite the saved TokenEnd in unpredictable ways.

As a caveat: The parser can add tokens back to be read before the next token in the scanner, unfortunately I do not have time to look into or handle those cases.