Relational: Unify `Lt` and `<`, a fix for pr #7783

Make long form and symbolic operators take the same path through the code.
This effects `Lt`, `Gt`, `Ge`, `Le`, their longer forms (`StrictLessThan`,
etc) and the symbolic versions (`<`, etc) which call `__lt__` etc.

Here is an outline of the approach:

1. If we come via `__lt__` than we do all we can to reduce to bool or
raise exception.  This can go through several classes' `__lt__` methods,
but in the end (currently `Expr.__lt__`) we ask `Lt` to make a
non-evaluated inequality with `evaluated=False`.

2. On the other hand, if we come from `Lt(lhs, rhs)`, we first ask
`lhs.__lt__(rhs)`.  Which will then either return a boolean, raise an
exception or eventually call `Lt` again but with `evaluated=False` as
above.

In this fashion, we always have the same result whichever form we called.
test_relational: fix some incorrect tests

`Gt(I, 2)` is supposed to raise TypeError, not give `false`.
Inequalities: UnXFAIL tests from pr #7783
Relational: don't use symbol ops `<` in `Lt` lest it reorder arguments

I encountered and filed issue #7951, where `x < p` can become `p > x`
even when both are sympified.  This adds tests.  Issue causes failures
in `meijerint._condsimp` and more specifically `subs` where an `cls=Wild`
variable was substituted for a regular symbol in an Inequality.

As a workaround (which is probably safer against this sort of bug), we
call `__lt__` and friends instead of the symbols.
test_relational: better tests for ineq flip test

Perhaps issue 7951 not fixable, so replace XFAIL test with a test
that specifically tests the workaround I put in place.
Relational: if simplify lhs/rhs not enough, try harder with equals(0)

Call `_eval_sides` when simplifying inequalities (this can be expensive
so we first try the existing simplify lhs/rhs approach).

A consequence of unifying `Lt` and `<` (the fix for pr #7783) is that
`_eval_sides` is no longer called in `Relational.__new__`.  Sometimes
this meant inequalities did not reduce to boolean when they did before.
Now we have the essentially the same code: if an expression previously
reduced to bool upon creation, it should now do so after simplify().
fix tests that fail due to Inequalities no longer simplifying automatically

Just a matter of putting `simplify()` around them.
solve_univariate_inequality: simplify inequalities after subs

Inequalities no longer simplify automatically, which caused some test
failures.  Add `simplify` calls to prevent this.  Only one of these lines
explicitly lead to failures; but other two lines are similar so changed
those as well.
Merge pull request #7987 from cbm755/ineq_op_fcn_same_nosimp

ineq `<` same as functional forms `Lt` and drop ineq simplification
NaN: remove erroneous docstring about inequality raising TypeError

This is an artifact of pull request #7776 and should not have been included.
Core: inequalities with NaN raise TypeError

NaN is indeterminant; for example the result of `0/0` could be
many values in the sense of limits (`5*x/x`, `x/x`, as `x` to zero).
By this interpretation, `3 < NaN` is not an valid comparison and
we raise the error.

Note this is different from the usual IEEE 754 Floating Point
system which regards all inequalities with NaN as false, using
the logic "3 is not determinably less than NaN".

Some tests in core/tests/test_numbers also updated.

This is discussed in issue #7773 and in pr #7776.
NaN: docstring update: doesn't exactly "represent" floating point nan

With changes to inequality behaviour, NaN behaves differently than
floating point nan.  We say "loosely related" instead.
meijerint: workaround NaN's in _check_antecedents

Inequality checks with NaN's used to be false.  Now they raise
TypeError.  This causes failures in meijerint.py's
`_check_antecedents`.  I've kludged it to get the previous behaviour
but its possible those NaN's are a symptom of a real issue.  Left
some comments and FIXME's in there for this.  Also labelled several
of the tests that hit the issue.