improve error handling (keywords: lenient, strict, assert)

[nitram509]

Motivation

There are different scenarios on how to treat errors like missing variabels when evaluating FEEL expressions.
Many programming languages favour "fail fast", but feel does not. Because of different scenarios, other implementations
offer choices to users, so they can decided how expression errors are treated.
Our implementation should also offer such choice.

Background

Consider the example price > 10 will evalute to null and does not raise an error.

The FEEL spec says that many expression errors are evaluated to NULL in the default lenient mode.
Also, it mentions a strict mode, were errors are reported straight (fail fast principle).
Additionally it say "[...] the evaluation MUST report or log diagnostic information and SHALL return null."
See section 7.3.8 in DMN spec).

Trisotech's implementations seems to favour a new flavor "B-FEEL", which behaves different then the default.
See https://www.trisotech.com/make-way-for-b-feel

Camunda v8 offers a custom builtin function assert() to raise errors
See https://docs.camunda.io/docs/components/modeler/feel/language-guide/feel-error-handling/

Implementation Ideas

• we could follow Camunda's assert() approach, which increases compatiblitiy
• as an alternative, we could introduce Eval-Options, so developers could change behavior of the interpreter
  • e.g. feel.ParseString("price > 10", WithStrict()) would raise an error, but using WithLenient() would not raise an error
• as an alternative, we could always return a Warning error object, and developers must then check, if the returned error val is of type warning
  • e.g. result, err := feel.ParseString("price > 10") ; if errors.Is(err, feel.Warning) then ...

Personally, I prefer the assert() solution, as it gives power to the end user, not the developer.