Fix misinterpretation of function arguments with parameters (#45)

[dyrpsf]

This PR fixes issue #45: when a FunctionDefinition has bvars with the same ids as
global parameters, SBSCL used the parameter values instead of the argument values
inside the function body.

The fix:

• Populate ASTNodeInterpreter.funcArgs with {bvarName -> argumentValue} before
  evaluating the function body in functionDouble(...) and functionBoolean(...).
• Restore the previous funcArgs map after evaluation, so nested function calls work.

With this change, identifiers inside a function body correctly refer to the function
arguments, even if parameters with the same ids exist in the model.

[draeger]

This looks good: The only comment I have is that we now have two parts of the code with nearly identical and comparably complex code. If further improvements or corrections are necessary, adjustments will need to be made to the positions. If it were possible to unify both methods by performing the pre- and postprocessing steps in sub-methods, maintenance could be simplified, and duplication errors could be reduced.

[dyrpsf]

@draeger Thanks for the review and the suggestion!

You’re right, functionDouble and functionBoolean share almost the same pre/post‑processing logic. I’ll extract that into a small private helper so the two methods only differ by how they evaluate the function body. I’ll push an updated commit shortly.

[dyrpsf]

Hi @draeger,
I’ve pushed a follow-up commit that factors out the common argument-handling logic into a private
pushFunctionArguments(...) helper. Both functionDouble(...) and functionBoolean(...) now use
this helper, so their bodies only differ in how they evaluate the function body, and the duplicated code is removed.

[draeger]

Well done solution!