Reason: the WL will de-correlated a condition in a subquery like
outer_expr>inner_expr, and also inner_expr<outer_expr, but store
both in a canonical form outer_expr>inner_expr. So, to convert the
2nd form to the canonical form it needs rev_functype(). As it will
also decorrelate outer_expr<>inner_expr, it needs '<>' to implement
rev_functype().

Consequences:
the introduction of Item_func_ne::rev_functype(), now returning the
same item type NE_FUNC (instead of UNKNOWN_FUNC), has an effect on the
range optimizer (look into get_mme_tree() which calls have_rev_func()
to see if it should study "b REVERSE-OP a" after failing on "a OP b");
thus some plans change.
It isn't a bad thing; so far, this:
EXPLAIN SELECT  c FROM t1 WHERE c<>0 AND (c XOR 0);
and this
EXPLAIN SELECT  c FROM t1 WHERE 0<>c AND (c XOR 0);
where not optimized the same way (differences in EXPLAIN)
because the range optimizer didn't deal with them equally;
while c>0 and 0<c where optimized the same way.
This example comes from the diff of i_main.range_myisam's result file.
This affects all queries which have "WHERE col" (because that's,
implicitely, 0<>col).
We get more use of the range optimizer, see for example the diff of
main.subquery_sj_mat_bka_nobnl's result file.

Reviewed By : Dag Wanvik <dag.wanvik@oracle.com>