Revert "remove log.is_zero routine"

This reverts commit de47eb297f822edea3b70b8d8cf094072833b806.
Cleanup log._eval_is_zero, add tests
Drop trivial log(1).is_zero test [skip ci]
Merge pull request #8053 from skirpichev/restore-log-is_zero

Revert "remove log.is_zero routine"
return 2 from _pi_coeff as per docstring
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
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