Fixed typos in four files
Catch some "flips" for inequalities with NumberSymbol's

e.g. pi > x was processed before to (-pi) < (-x)
Merge pull request #7918 from skirpichev/oo-ineq-2

Catch some "flips" for inequalities with NumberSymbol's
Merge pull request #7990 from raj454raj/typo

Fixed some typos
Revert "simplify Mul._eval_is_even"

This reverts commit 1b436d045107f610b51065e03eff0dbdf92e76c5.

This "simplification" produces loop, because Add._eval_is_odd
call in turn is_even property on Add's arguments.

fixes #8050
Merge pull request #8052 from skirpichev/8050-fix

Revert "simplify Mul._eval_is_even"
bounded and unbounded are not antonyms

tt is currently possible to create a meaningless set of assumptions:

neither
    Dummy(zero=True, bounded=False) nor
    Dummy(zero=True, unbounded=True)
raise an error.

If we assume finite == !unbounded in assumptions, we
create an alias: finite=False is the same as unbounded=True
and vice versa. We don't want to do that. What we want is
behavior like integer and noninteger:

Dummy(integer=0) is not the same thing as Dummy(noninteger=1).
A noninteger is commutative, complex, hermitian, noninteger,
nonzero, and real while integer=0 is only commutative -- nothing
else is known about it (other than that it is not 0).

/!\ In general, it is much easier to comprehend what one means
by using only true attributes to desccribe it. If something is
not zero but still complex, say nonzero=True instead of zero=False.

So assumptions.py has been modified to make the following true:

```
finite   : 0 < abs(x) < oo
bounded  : 0 <= abs(x) < oo
unbounded : abs(x) == oo
```

The same is also true for zero and nonzero. If nonzero is True you
are talking about a complex number that is not zero. But if zero is
False you are only talking about a commutative object that is not
zero.

In addition, we now use is_unbounded = True not is_bounded = False
in the few places where this is defined. The former is an affirmation
of what the object *is* not an indication of what it is not.
make sure nonzero.is_complex is True
make all NaN is_* properties None -> False

I believe the answer to S.is_Q should apply the following logic:

if no part of S is in Q:
    return False
if all parts of S are in Q:
    return True
return None

So S.NaN.is_positive should be False: NaN never appears amongst
the postive numbers in the same way that S.NegativeOne never
appears amongst the positive numbers. Returning False has no
other implication about what the object *is*, only what it is not.
None should be returned in a case like Dummy(nonnegative=1).is_positive
since nonnegative might be 0 or positive.

Returning None means "I don't know, ask someone else." When expressions
which could lead to a NaN are encountered _eval_is_ routines should
return False instead of None
so that all routines should not have to be queried to determine
what the expression is. e.g. if an expression zero*unbounded is
encountered False can be returned and this should make it easier to
return a result for whatever attribute is being sought for that
expression.

Also make sure that NaN.is_complex is False.
fix Mul._eval_is_* routines to match new assumptions
unbounded -> infinite except in sets and indexed
fix Mul._eval_is_(integer|rational)

Also, remove irrational since being irrational is the same as
having rational=False, real=True. In general, only the positive routine
needs to be defined if the negative is truly the opposite. However,
is_positive and is_negative need to both be defined because not being
positive doesn't mean an object is negative -- it could be zero.
fix Mul._eval_is_positive to recognize imaginary factors
reorder Mul._eval_is_* routines
simplify Mul._eval_is_odd routine