Fix throwing on accessing CLR FunctionDeclaration

[lofcz]

I'm open to finding a better solution to the problem described below, as the current fix has weird ergonomics.

Accessing FunctionDeclaration of a MethodInfoFunction (CLR functions) currently throws - the test* included describes the scenario. I believe accessing the property should never throw (I hate linking to MSDN, alas: https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/property?redirectedfrom=MSDN).
This forces a sprinkle of ! in the codebase in places where we know the function is not a CLR function (this is the part I don't like).

*I've included two tests now, one for the delegate, and one for the method info function.

Unrelated to this, for the debugger I'm working on, I'd need to make at least some information of MethodInfoFunction and DelegateWrapper public to provide information about the native function (get the parameters, largely the same thing Jint does internally). This is outside of this PR's scope, just announcing ahead of time to discuss, should there be objections to that.

This would be:

• DelegateWrapper: Delegate _d
• MethodInfoFunction: MethodDescriptor[] _methods, possibly ClrFunction _fallbackClrFunctionInstance

[lofcz]

The failing test is something flaky with async implementation, unrelated.

[lahma]

Thank you.

[lahma]

Unrelated to this, for the debugger I'm working on, I'd need to make at least some information of MethodInfoFunction and DelegateWrapper public to provide information about the native function (get the parameters, largely the same thing Jint does internally).

So I guess you need the typed params and it would not be enough to implement CLR method's custom IFunction descriptor which would return the names which IFunction has a property for. Creating such fake wrapper would also offer always non-null function declaration.

[lofcz]

I pondered the IFunction idea but ultimately I don't see the fake wrapper as able to expose the data I need (typed params). If you are ok with it, I can create a PR tomorrow exposing the members listed above.

Probably also XML doc for IFunction? FunctionDeclaration to explain that it's always null for CLR functions.