Query/Perf: deep investigation on shaper perf changes regarding AOT

We made some changes to the way we construct shapers in preparation for AOT, and some of those changes caused perf regressions. We identified a number of potential fixes but we really need to get to the bottom of what EXACTLY is happening. Specific issues to deep dive into:

- compiling resolver lambda in interpreter mode vs regular - there is a perf impact when the result of interpreted compilation is itself a delegate and that delegate is invoked multiple times (e.g. ValueComparer arrays passed to PopulateIncludeCollection. What about delegates invoked only once? What about resolver that doesnt produce a delegate but some arbitrary object instead? How interpreting vs regular impact query compilation time in general?

- In some places rather than producing a delegate using LiftableConstant, we pass `Expression>` as argument when building a method using Expression.Call (rather than evaluating and passing ConstantExpression containing compiled delegate). We found that number of those negatively impact performance (i.e. performance gets better when those are compiled and passed as constants). What's going on here? We are compiling the entire shaper expression in the end, shouldn't perf be the same as compiling piecemeal?