LEAST/GREATEST nullability work

[roji]

@maumar tiny fixup PR; if EF.Functions.Greatest/Least is used over a nullable value type, that trips up the debug assertion (SqlExpression nodes can't have a nullable value type). So this unwraps that before creating the function.

Fixup to #32338

[roji]

Turning this into a draft, there are unfortunately some other nullability-related aspects of this that need to be taken care of...

PR has been redone and needs a new review

[roji]

Nullability analysis

There are two diverging behaviors across databases with respect to NULL arguments (there's a reason I procrastinated on this work...):

• PostgreSQL and SQL Server ignore NULLs - GREATEST/LEAST only return NULL if all arguments evaluate to NULL. In that sense the behavior is similar to COALESCE.
• SQLite, MySQL and MariaDB propagate NULLs - NULL is returned if any argument evaluates to NULL (more standard behavior).

We have three cases where we translate to GREATEST/LEAST:

• Math.Max/Min. These have a restricted set of overloads over numeric CLR types - only non-nullable - so it's OK.
• Queryable/Enumerable.Max/Min. These do have overloads for nullable int, etc., where null is returned when all arguments are null (or there are no arguments); in other words, the PG/SQL Server behavior. That means we can use GREATEST/LEAST for all these overloads on SQL SERVER/PG, but for the other databases we can only use them for the non-nullable overloads.
• Our own EF.Functions.Greatest/Least (for any type). Here, as usual with EF.Functions translations, we just translate to the database function, so the behavior will be different across databases with respect to nullability.

Changes in this PR

• Generation of GREATEST/LEAST moved from SqlExpressionFactory to RelationalSqlTranslatingExpressionVisitor, defaulting to no translation (forcing the provider to implement). This was done because:
  • The functions aren't always supported (e.g. older SQL Server), and everything on SqlExpressionFactory is currently always supported (see API review comment).
  • Even when supported, the diverging NULL propagation behavior means we want each provider to supply their own implementation with the correct nullability propagation etc.
• Only translate {Queryable,Enumerable.{Max/Min} to GREATEST/LEAST if the provider's nullability propagation matches .NET (i.e. return null only if all arguments evaluate to null), or if the elements are non-nullable.
• Generally better factoring.

[roji]

@dotnet/efteam I've brought this back and done the necessary fixed, see above.