fix(agama): serialization of undesired content when a flow crashes

[jgomer2001]

When a flow A calls another B, if B crashes and A catches the crash, an undesired behavior occurs when hitting RRF (at A): all variables of B including the expection that caused the crashed are being serialized

Example for more clarity:

Flow A
    ...
foo ="bar"
result | E = Trigger B
...
E = null
RRF "blah.ftl"
...
Finish ...

Flow B
    ...
foo2 = "bar2"
Call something.that#crashes // --> Java exception occurring here
...

In this case, variable foo2 plus the exception is serialized when the RRF at A is executed. This makes no sense because flow B is already "gone" by then. Surprisingly, even if the caught exception is nulled (E in the example), it tries to serialize it

It is uncertain why Rhino is doing this

[jgomer2001]

After many rounds of playing with transpiled code I discovered the situation is presented whenever a (flow) function terminates execution abruptly, be it caused by a Java Call that threw exception or by any other error, e.g. accessing a member of an inexisting variable

Even Java Calls that have exception handling (like var | E = Call ...) provoke the undesired serialization when the exception is caught!

Serialization of arbitrary variables is already problematic. It is necessary to avoid serialization of unnecessary variables at all cost. A solution has to address the following:

• Ensure Calls are always "successful". This can be done by wrapping the original Java invocation with a Java try-catch and returning a pair with the result of the invocation plus the exception, if any. This way, Java exceptions are not handled at Javascript level
• Ensure functions do not throw. This can be done with a big try/catch block for every function and returning the (Javascript) error, if any, from the catch block

With the two points above, functions will always return a definite value. To implement the solution (ie. no throws) a transpiler rework is required