Two different implementations of FEEL execution

[baldimir]

Currently there are two different implementations that execute FEEL - one in interpreted mode and one in compiled Java mode (code generated). The execution uses some common mode on some places, but not everywhere. This should be fixed. Business logic of the evaluation should be encapsulated in a common module which is used by both interpreted execution and compiled execution.

Pointers:

• AST nodes
• Compiled execution, e.g. here

[gitgabrio]

Based on analysys, I found that FEEL usage itself is not duplicated, i.e. both code paths ultimately invoke
FEELFunction#invokeReflectively(EvaluationContext, Object[])}

The difference is the overall "context" and the way messages/errors are dealt with:

1. in the intepreted way, the MsgUtil.report is used in case of errors, and the returned EvaluatorResultImpl has a flag to indicate a failure
2. in the compiled way, the EvaluationContext.notifyEvent() is invoked in case of errors, and the returned object is the result of function evaluation itself.

Merging the two paths seems pretty error prone and anyway the core FEEL implementation itself seems not duplicated.

@baldimir @yesamer