increase evalf workprec more quickly

There were some oddities here that have been here since this code was
added. If the desired precision was not obtained, the precision appears
to want to increase in a doubling fashion based on the iteration number
but that computed value is never used by using the expression prec -
max(-2**i, accuracy)

Let's say prec was 15 but accuracy was 10 on the first iteration: the
new workprec would increase by 15 - max(-1, 10) = 5. If accuracy was 12
on the next step the new workprec would be 15 - max(-2, 12) = 3.
So the workprec is increasing but in a very slow fashion based
on the difference between the desired prec and the accuracy.

If a result of 0 was calculated, however, this would cause the working
prec to increase at a rate of prec + 1 until the maxprec was reached
because the accuracy for a scaled zero is -1. So, for example, if a value
of 0 is still being obtained when i=10 a change in prec is calculated
as 15 - max(-2**10, -1) = 16.

In both cases the value based on iteration (2**i) is being ignored.

With the changes of this commit, the larger of 2**i and prec is used as
the increment for workprec when accuracy != -1, otherwise workprec
will double each iteration.  (When accuracy=-1 and the integral really is
zero, the time that it takes to return an answer will depend on how fast
one gets to maxprec, e.g.

Integral(sinh(x)**2-cosh(x)**2,(x,-oo,oo)).n(2) takes about 300 sec now
but took 500 seconds if the same method as when accuracy!=-1 is used.
(master takes longer still).
is_zero and free_symbols modifications

is_zero is needed to identify alternate *trivial* forms of 0 as
in Integral(0, ...). It should never do more than look for a literal
0 someplace. For this reason, the Integral.is_zero routine was modified
and the advanced processing for other mostly trivial cases of an integral
being 0 was moved to the doit method.

foo.is_number is equivalent to not foo.free_symbols but is a faster way of
arriving at that answer because is_number will fail if a single free
symbol is encountered. For this reason, the Integral.is_number routine
was modified.

foo.free_symbols should give any free symbols in the expression *as
written* without any regard to whether those symbols will disappear after
simplification of some sort. The test for is_zero was removed from
expr_with_limits calculation of free symbols for this reason.

Other comments about the rationale of these changes are in the test
suite (esp in test_basic) so that anyone changing the behavior will be
sure to see the desired state of affairs.
add check for is_zero in re and im
change _evalf to _evalf_binprec to make difference obvious
allow .evalf to take None for n; unify evalf arglist names
raise TypeError if subs for evalf is not a dictionary
add literal flag to evalf
modify is_comparable
use literal flag in assumption related to numbers
7642: KroneckerDelta more judicious in evalf; = 0 for nonzero diff
make is_positive and is_negative like new assumptions
modify test which takes a long time