[FEATURE] Expression parser

[tommens]

Describe the new functionality you would like to see
In order to make the Calculator usable in practice, it needs to accept an input parameter of type string. This string will be read, parsed and converted into a syntactically valid expression, or a syntax error will be returned if the string does not respect the correct syntax. Valid expressions will be evaluated, and the result of the evaluation will be printed on the console.

In order to achieve this functionality we need an expression parser:

• In its most basic functionality, the expression parser will only accept as input properly balanced expressions with parentheses in the right places. E.g. "((4 + 5 + 6) * (7 + (5 / 2 / 7)) * 9)". The parser should be able to read expressions in either prefix, infix or postfix notation. E.g. "(+(4,5,6),+(7,/(5,2,7)),9)" for prefix; "((4,5,6)+,(7,(5,2,7)/)+,9)" for postfix. The parser should not be space-sensitive, the presence or absence of spaces, tabs and so on should not make a difference when parsing. Slight variations of the allowed notation could be considered, for example a pre- or postfix notation with spaces instead of commas as separator between arguments. E.g. "(+(4 5 6) +(7 /(5 2 7)) 9)", which incidentally also corresponds to the way of writing expressions in the Schema functional programming language. When implementing this functionality, the "output" of an expression should be consistent with the accepted input. (In other words, any valid string given as input should return an equivalent string after converting it to an Expression and back to a string. Conversely, any string generated as output from an expression should be acceptable as input to the parser without any errors...
• A more sophisticated functionality should take into account operator precedence to avoid superfluous parentheses. For example, if we know what * and / have precedence over + and -, then we can simplify the expression "((4 + 5 + 6) * (7 + (5 / 2 / 7)) * 9)" to something like "(4+5+ 6)(7 + 5/2/7)*9".
• This feature needs to be accompanied by the necessary unit tests and cucumber BDD tests.

Is your feature request related to a specific need or problem?
Without a proper expression parser, the caclulator is not really practically useful, since creating expressions manually in terms of object trees is very cumbersome, error-prone and time-consuming.

Additional context
Several Java libraries exist for creating parsers, it is recommended to choice the most appropriate one of them rather than to reinvent the wheel from scratch.