Fix #889: support arrow lambdas as delegate (System.Action/Func) arguments

[DavidObando]

Fixes #889

Root cause

Arrow lambdas (() -> expr) could not be passed where a void-returning delegate such as System.Action was expected, while the func() { ... } statement-body form worked.

This is a natural-typing gap. An arrow lambda whose trailing expression yields a value — e.g. () -> called = called + 1 (an assignment evaluates to int32) — infers the natural type () -> int32, which is not convertible to () -> void (System.Action). The func() { ... } form has a statement body, so it naturally returns void. This matches C#, where var f = () => x++; is a Func<int>; the fix is therefore target-typing the literal to the delegate parameter, not changing its natural type.

Fix

Void-izes a func/arrow literal to a void-returning delegate by discarding its trailing value — mirroring the existing func statement-body behaviour and C#'s lambda-to-Action conversion:

• LambdaBinder — when the target delegate returns void, pin the inferred return type to void; the erased-adapter rewriter now drops the trailing value (return <v>; → <v>; return;), producing valid void IL.
• ConversionClassifier — void-ize function literals on direct BindConversion paths (covers let a Action = () -> ...).
• OverloadResolver — void-ize literal arguments at user function / constructor / instance call sites before the wrong-argument-type gate.
• OverloadResolution — add a lowest-priority LambdaToVoidDelegate conversion kind so that a value-returning Func overload still wins betterness, while enabling imported-CLR method resolution (e.g. CliEnvironment.RegisterRestore(Action)).
• ExpressionBinder.Calls — void-ize literal args on the static imported-call path, mirroring the instance path.
• MemberLookup — add TryGetDelegateFunctionTypeFromSymbol to resolve the function-type shape of native function types, named delegates, and imported CLR delegates.

Void-izing is restricted to function literals, so natural typing for function-typed values is preserved and existing overload-resolution behaviour is unchanged (e.g. Task.Run(() -> ...) still prefers the Func overload).

Tests

New test/Compiler.Tests/Emit/Issue889ArrowLambdaActionEmitTests.cs (CompileAndRun + ilverify) covering:

• arrow lambda → System.Action variable (assignment and +=),
• arrow lambda passed to a user function expecting Action / func(int32),
• value-returning func() int32 keeps natural typing,
• arrow lambda passed to an imported static method taking System.Action (mirrors the issue; helper assembly emitted via PersistedAssemblyBuilder).

Local results

• dotnet build GSharp.sln -c Release --no-restore -graph → Build succeeded (0 warnings, 0 errors).
• dotnet test GSharp.sln -c Release --no-build → all green: Sdk 38, Extensions 104, Interpreter 308, LanguageServer 326, Core 3340 (1 skipped), Compiler 1347. 0 failures.