Created a Set Complement class

Sergey B Kirpichev <skirpichev@gmail.com> helped with some fixes
in the PR's https://github.com/hargup/sympy/pull/5 and
https://github.com/hargup/sympy/pull/4

* Remove duplicated UniversalSet class
* Reenable some old tests
* Fix random test failure

Conflicts:
	sympy/sets/tests/test_sets.py
Write printers for Complement
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).
Merge pull request #7462 from hargup/set_difference

Created a Set Difference class
Merge pull request #7850 from smichr/mods

increase evalf workprec more quickly
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.
move Integral.is_zero to _eval_is_zero
make log._eval_is_zero more naive: no simplification
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

This only takes a long time in this branch because an attempt
at evaluating the integral is attempted now...and that integral
is zero and this takes a long time in the evalf routine. Since
we are only testing the type of arguments in this test (not
the evaluation of the integral) it seems reasonable to change the test.