mod tracks precision of Float

Float already implements the tracking so the calculation is
passed off to Float rather than being handled in Rational.

Checking a ratio seems to resolve Float(n*f)%Float(f) better than
the mod calculation (i.e. the ratio shows that the result is the
Float equivalent of n, hence no remainder).
1606: as_sum error if integral is not definite
2191: collect_const can collect Numbers

By using Factors, it is much easier to collect negative terms
if so desired since the -1 is always separated from the Number.
But something documented in the code is the desire *not* to let
Integers be divided by radicals, e.g. 2/sqrt(2). Although that
is a legal operation, it would turn 2 + sqrt(2) into sqrt(2)*(1 + sqrt(2)).

Although _keep_coeff handles the general need of making an unevaluated
Mul, there is no function to make a well-formed unevaluated Add as is
needed in collect_const. Although Add(*args, evaluate=False) can be
done there is no assurance that the args are in the right order. They
are only ordered when they are passed with evaluate=True through
Add.flatten...but that undoes the unevaluated Mul in the process. So,
until that is fixed, _unevaluated_Add is a workaround.

clean up collect_*

There were some dependencies between collect_sqrt and collect_const that
were reduced. collect_sqrt is more specialized in terms of collection
so it does the preprocessing with content_primitive; this is no longer
done at the lower-level collect_const routine. Also, collect_const
processes items in an ordered manner, so collect_sqrt no longer needs
the sorting of vars before the call to collect_const.
docstring and number literal edits
fix unrad code in solve
Add Demian Wassermann to AUTHORS/aboutus. Welcome to SymPy!
Merge pull request #1913 from smichr/mod

mod prec, as_sum error, collect on Numbers