Avoid transformations to Enumerable nodes for custom SqlOperators

Most Enumerable converter rules apply a transformation as soon as the RelNode class and its convention match those defined by the rule. However, there are use-cases that we would like to restrict the matches even further to avoid generating unimplementable plans that will fail at runtime.

The most prominent example comes from extending the standard operator set with new SqlOperator s that appear in filters and projections as part of a row expression (RexNode). If we use the default instance of the EnumerableCalcRule we might end-up with a plan that will fail at runtime since the new operator is not handled by the Enumerable convention. Most likely there is a RelNode in another convention that can handle this new operator.

We could avoid such undesirable transformations by allowing instantiations of the Enumerable converter rules with user-defined predicates. This also means adding public constructors to the rules that currently they do not have one.