Once we can AOT-precompile the materializer (1st part of the query pipeline, #25009), we can also pregenerate final SQL (2nd part of the query pipeline).

• The main design question here is to decide when/how much to precompile. This part of the query pipeline caches on the nullability of the parameters (since null/non-null results in different SQL), so the number of SQLs we'd need to generate grows exponentially with the number of parameters. It probably makes sense to choose an arbitrary (possibly tweakable) threshold for the number of parameters to avoid this explosion.
• To reduce the permutations, our AOT infrastructure can examine the nullability of the parameters (i.e. captured variables) being referenced; a non-nullable parameter requires only a single SQL, not two. For reference types, the Roslyn symbol should be able to tell us whether the local variable being referenced is nullable or not.
• In any case, we're most likely going to need to keep this part of the query pipeline at runtime. This is both because of the permutation explosion described above, and also because we sometimes generate SQL that isn't cachable (e.g. constantization of array.Contains()).