modify equals and is_constant

** Inline notes describe why the minimal_polynomial is not being used
at present to prove an nsimplify result. solve, however, may be able
to prove that an expression is zero by getting a self-consistent solution
when solving for a surd of the expression. An test was added for this.

** In addition, cancel is used on the expression to try facilitate
simplification to zero (and an expression that motivated the change
has been included).

** don't use equals in sign and abs because it can be very slow

Thanks to Mario Pernici for finding good examples of when the
method used in equals is going to take a long time to solve.
The discussion that I had with him is on the PR 1925 page.
foo.is_number == not foo.free_symbols; update docstrings

To know whether something can be evaluated to a real number with
precision, use is_comparable; to know if it can be a complex number
with precision use something like

all(i.is_comparable for i in foo.as_real_imag())

is_comparable should make the call to is_number.
Merge pull request #1990 from smichr/isnumber

is_number docstrings updated; equals and is_constant modified
3070: remove Neg from cse_opts and use different mechanism

Some objects, like RootOf, don't interact well with the Neg mechanism
that cse uses to keep track of Adds that can have a -1 extracted.

1) wrapping an expression in Neg changes the perceived degree of the
expression for Poly (Poly(x**2) is degree 2 but Poly(Neg(x**2)) is
degree 1. Issue 3070 shows why this leads to an error.

2) if Neg is used like a kern so that y - x -> -Neg()*(x - y) that
still causes problems with RootOf because this creates a new generator:

>>> class Neg(Expr):
...   @property
...   def is_commutative(self): return True
...

Poly is ok
>>> Poly(Neg()*x)
Poly(x*Neg(), x, Neg(), domain='ZZ')

>>> RootOf(Neg()*x)
Traceback (most recent call last):
 sympy.polys.polyerrors.PolynomialError: <univariate message>

So instead of using Neg, an unevaluated Mul is simply used. Instead
of replacing y - x with -1*(x - y) (since that will be hard to find later
because Muls can have a leading -1) a leading (1, -1) is used instead:

>>> Mul._from_args([S.One,S.NegativeOne])
-1
>>> _.args
(1, -1)

Muls should not start with a leading 1 and even if something does
(because someone used an unevaluated Mul) the storage of the -1
will make the replacement correct in terms of mathematical equality,
1*-1*x is eventually replaced with -x.
fix tests