Query: Allow store types and type facets to be set explicitly (EF.StoreType)

[smitpatel]

#4937 introduced logic to infer Unicode-ness for literals when comparing to column. It works well for simple cases when one side of comparison is ColumnExpression. Though there are complex cases in which we are not inferring the information correctly atm. For e.g.

1. If one side of binary expression is subquery selecting one element of a column then the other side should have same facets as the column being projected in subquery.
2. Operators like concat which return string type values should pass uniform information towards parent because the siblings of concat should have same unicode-ness as concat. (See test Non_unicode_string_literals_is_used_for_non_unicode_column_with_concat)

For cases like above, we can improve logic to propagate information. If it is too hard to do then we should add functions like AsUnicode & AsNonUnicode.

[smitpatel]

Also cases of SqlFunction like CharIndex (comes from String.Contains method) the argument should have same type mapping. Though That could be different for individual functions.

[ajcvickers]

Note: when designing/implementing this, consider the case for parameters passed to FromSql, etc. See #8895
Added comment to that issue.

[ajcvickers]

See also comments in #11921

[ajcvickers]

See also comments in the thread here: #6717 (comment)

[roji]

Another issue which shows the need for a way to explicitly specify a store type: npgsql/efcore.pg#561.

[smuthuvels]

I am using EF Core 2.0.3 and I am getting the same issue for Contains search. Do you have any fix for that?

[smitpatel]

blocked on #13192

[bricelam]

I added a mechanism for query translators to provide explicit type mappings for function arguments and results in PR #13648. This allows us to fix individual cases.

[roji]

Another possible need for this: setting facets in order to allow something to participate in a set operation (currently set operations over types with differing facets isn't supported, #19129).

[roji]

Note that this issue has been a bit ambiguous; we can use this issue to track explicitly forcing a type mapping on an arbitrary node, whereas #35045 is about adding an actual CAST() node into SQL.