3533: nfloat fix

A proper evaluation of an expression cannot be done by substituting
evaluated numbers into the expression as a result of precision issues.
Instead, numbers must be evaluated in groups, e.g. (sqrt(3) - sqrt(2)).n()
rather than sqrt(3).n() - sqrt(2).n(). Often this doesn't matter much,
but as the added test shows, it does matter.

evalf needs a serious overhaul to make this right, too, since if evalf
(instead of nfloat) is used on the added expression for this issue, the
same mistake occurs. This is because _matches_commutative deals with
args arg-wise (instead of in lumped args which are all numbers).

The way evalf should work, I believe, is:

1) expr.evalf()
  a) expr.is_number is False
    i) if subs given, then do the subs thing in evalf
    ii) else call to expr._eval_evalf (with n, not prec) to find the
       numbers and pass them back to evalf and replace them in the
       expr; if there is not expr._eval_evalf routine use the Mixin
       routine, changed to apply evalf to each of the args (rather
       than returning None as now).
  b) normal evalf when expr.is_number
3533: fix for Add/Mul evalf
simpler 3533 nfloat fix
use _aresame in xreplace test of equality

It is possible that A === B even though A and B are not structurally the
same, so the more strict _aresame() is used to test for exact equality.
solve implicitly for anything except numbers

There is no reason to disallow solution of an equation for
a given object, so it is possible to isolate objects which are
not symbols as long as they are not numbers -- numbers should only
be themselves, so there should be nothing to solve for. Functions
like cos(1) are numbers and so are undefined functions like f(1)
but the latter are allowed since they don't evaluate to a number.
supply non-numeric objects as symbols if necessary
add note about implicit solving

Although solving for numbers 1, cos(1 + sqrt(2)) could be added,
this has not been added at this time. To do this, the user will
have to handle the substitution on their own.

Part of the reason this was avoided was because if expressions
are given that are themselves numbers, then trying to rearrange
for a number in that expression can only be done if the expression
itself is 0 -- if it's not then any inferences made from it are
invalid.  One has to watch for -1 that is hiding in all subtractions, too.

e.g. if eqs = Tuple(4 - sqrt(2), sqrt(2)/3 + 1)
>>> eqs = Tuple(4 - sqrt(2), sqrt(2)/3 + 1)
>>> eqs.subs([(1,a),(4,b)])
(-sqrt(2)*a + b, a + sqrt(2)/3)
>>> solve(_)
{b: -2/3, a: -sqrt(2)/3}

but compare to the solution after masing off the -1

>>> solve(eqs.subs(-1, Symbol('-1')).subs([(1,a),(4,b)]), a, b)
{b: -sqrt(2)*-1, a: sqrt(2)/(3*-1)}
>>> Dict(_).subs(Symbol('-1'), -1)
{a: -sqrt(2)/3, b: sqrt(2)}
Merge pull request #1679 from smichr/3533

3533
solve can solve for any expression -- no checking
Updated link to SymPy development wiki
Dropped dead link to J.C. Faugere's lecture notes.
Changed to HTML entity codes for wikipedia reference, since closing
parenthesis was not parsed properly by linkcheck.
Dropped dead link to Henri Darmon's Course for 2005-2006.
Updated link to reference on how to add packages to YaST.
Updated repo link to newest openSUSE.
Dropped dead link to Handbook Of Mathematical Functions.
Updated link to Borwein's paper on the Reimann Zeta Function.
Invalid linebreak in link.
Encode parens in wikipedia links.
Encoding parens in wikipedia link.