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

Since NaN is not even complex it cannot have any of the attributes of
the complex numbers. So things properties like positive, odd, etc...
should be False. For example, NaN never appears amongst
the postive numbers in the same way that S.NegativeOne never
appears amongst the positive numbers so False should be returned for both.

Returning False has no
other implication about what the object *is*, only what it is not.
None should be returned when there is a question about whether the
statement is true, as in Dummy(nonnegative=1).is_positive. Since the
symbol might be 0 or positive we cannot say for sure that it it
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 for is_real and then all the
implications of that can be propogated by the assumptions system.
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
shift names bounded->finite->_finite

This definition is in accordance with Python's math.finite definition
which includes 0. The identify a number that is finite and nonzero,
use foo.is_finite and foo.is_nonzero.
simplify redundant test for NaN
do not use bare </> tests of things which might not be Numbers
rationals are finite
unXFAIL neg_symbol_falsepositive [skip ci]
remove superfluous attributes
[decide] _finite -> nzfinite until better name is chosen [skip ci]
merge with master
add docstring to as_dummy()
make Mul._eval_is_real aware of complex=1,real=0,imaginary=0 terms
make Add._eval_is_* methods infinite-aware