Add support for basic type inference within lambda functions

[acizmarik]

This PR adds support for type inference within lambda functions.

Overview

We try to infer information about lambdas based on provided arguments and context in which the lambda is being used. Current biggest limitation is that we do not take into account lambda bodies. Still, in most cases, this simpler approach should work and infer correct type information. Following situations are covered by the type inferer:

1. Lambdas as method arguments
   • Gather usable method candidates
   • Based on other method arguments, resolve open generic types and refine method candidates (in each iteration we have more accurate information about the method call)
   • Based on refined method candidates and resolved generics, try infer lambda type
2. Top-level lambdas, such as SortChanged on grids
   • Here we must rely on the computed binding's expected type
3. Compilation into Action<..> vs Func<..> vs Predicate<>
   • Originally presented as Fixed issue with lambdas and System.Action #995 (abandoned)
   • DotVVM distinguishes 2 statements: assignment and method invocation
   • If user specified a valid statement as lambda body and lambda should be assigned into an Action<..>, return value gets discarded and as such the compilation result can be treated as an Action<..>
   • This implementation uses type inference to decide whether we need to discard return value or not

Breaking change

Interface IBindingExpressionBuilder was altered by adding an optional parameter to its Parse method. Regardless, I do not think that this change could actually break someone

[acizmarik]

I added a test that showcases this feature works with methods introduced by #965. It should work nicely together with method calls, but also with extension method calls.