Issues 212, 256: Adding support for internal lambdas to reference parameters from the parent lambda

[holdenmai]

Issue #212 was really the issue here.

When replicating the code given in Issue #256 the last "x.Grade" was being immediately resolved as the value from the parameter was being inserted directly. In the previous implementation of "InterpreterExpression", it was creating it as a new ParameterExpression.
This code update captures the "parent" ParameterExpressions as identifiers.

This is essentially what happens with compiled code, so instead of us having to create a class, Expression actually allows us to reference the existing Expression as an Identifier.

Fix #212, #200, #256

[davideicardi]

LGTM! Thank you!

@metoule do you see problems?

[davideicardi]

Do you think that this PR will solve #212, #200 and #256?

[holdenmai]

Yes it will.

This will also make it so that #213 can be closed without merging as the settings Identifier dictionary has become our "locals" dictionary.

I just thought of a couple more cases to verify that we are only able to access parameters defined in the enclosing lambda, not a parameter defined by an adjacent lambda.

Will get those included as soon as able.

[holdenmai]

Test cases to cover duplicating parameter names in other lambdas have been added.

[davideicardi]

Thank you @holdenmai . It looks like a very nice feature. There is just a failed test.

[holdenmai]

Unit test has been fixed. It actually had a bad lambda declaration that would not have compiled with real code. I guess the only issue with that is if a consumer of this package had also done the same thing in the past.

[metoule]

That's even better than my attempt in #213 (and simpler :)), thanks a lot!!