Binary ineq like `<` should give same as functional forms `Lt`

Is this the right fix for underlying issue in pr #7783?

- [x] pass tests from #7783 
- [x] pass rest of `test_relational.py`
- [x] make sure non-evaluated but potentially evaluatable still works.  E.g., things like:
````
e = Lt(7,7, evaluate=False)
e.doit()
````
- [X] Make sure `e = Lt(x,y); e.doit()` takes same path.   update: it does.
- [X] consider removing `_eval_sides` from code, or make it specific to the Equality/Unequality.  Update: for now, I call it from `Expr.__lt__` (which may not be the "cleanest" given that its a `_` method.)
- [x] consider the broader test suite.
- [x] There is bound to be some fallout...  Update: surprisingly little so far, all changes local to `expr.py` and `relational.py`.
- [X] Consider: Could `lhs.__lt__(rhs)` return None?  `Equality` and `_eval_Eq` use this but `__lt__` is not a helper function so not sure its useful here...  Update:  current approach seems to be working.
- [x] Are any documentation changes needed?  E.g., should the docs contain something like my explanation of the approach given in the commit message?  No: there are comments in the code and the documentation in `GreaterThan` already implies `>` should be the same.
> Why these calls to _sympify? It looks, we call such methods with already sympified lhs and rhs.

Unless it is (incorrectly) called directly.  A user might do this (for example, she is supposed to call `e = Lt(2,2*x)`, `e.func(1,x)`, but uses `e._eval_relation(1,x)` instead...)  I'd prefer to keep it.

> Usually we don't test private methods. Is there reason why we need this?
 
@skirpichev Its just there to test the _sympify calls above...  I could remove?