Move custom rf class outside the combsimp definition

This fixes, or rather, works around, a bizarre caching issue involving classes
defined inside functions.  See the discussion on pull request #1710.
fixes factor(), separatevars(), combsimp() from Issue #6280
Update ask.py

TautologicalHandler is in _val_template + "common" + TautologicalHandler
Changed tol on Complex and Real field to None

Fixes simplification issue #7263. Added test to check issue in
test_simplify.
Fixed travis errors

Direct comparison of expressions lacks enough precision for ==.
Comparing numerically now with evalf().
Show that init_session() runs init_printing()
Adds Derivative.as_finite_diff() and core.finite_diff with finite_diff_weights and apply_finite_difference
Change default step of as_finite_diff from sympify('h') to 1
Fixes Py3 error for test range+range
Moved finite_diff from core to series. Extended doc of finite_diff.
Updated Derivative.as_finite_diff() doc, tests and default step-size.
Merge remote-tracking branch 'upstream/master' into finite_difference
Fixed/updated docstrings with new master
polyroots: always refine all roots

Previously if the given root was already converged, it wasn't refined. But this
seems to increase the number of iterations needed to converge considerably.
polyroots: Raise error if convergence not achieved
polyroots: chop small numbers in "cleanup" mode

Previously only small real or imaginary parts were chopped. But if abs(x) is
close to zero, we want to chop this case as well.
polyroots: use `extraprec` argument

Previously this argument was not used at all by a mistake and instead the
default value 10 was assigned directly.
polyroots: fix tolerance calculation

We now set the tolerance `tol` directly equal to `ctx.eps`. This is the right
way to do it, since if more working precision is needed, the user needs to
assign the `extraprec` argument.
Refactor nroots() to make it more robust

The following changes were made:

* The polynomial coefficients are always converted to integers. Previously, a
  floating point number was used instead, which loses accuracy, and then for
  higher order polynomials (e.g. Legendre of order 64) one has to use large
  working precision just to represent polynomial coefficients accurately
  enough (otherwise one gets inaccurate roots, for example complex roots
  solution instead of real ones). Now this problem is completely avoided.

* We set extra precision in polyroots() based on the polynomial order.
  "10*order" seem to work well. This formula can be adjusted. This takes care
  of the problem that higher order polynomials suffer from numerical
  cancellation.

* We remove the `error` argument. Now the error is always either lower than `n`
  digits, or an exception is raised.

* The roots are now ordered by mpmath, which returns the correct ordering (real
  roots first, then complex ones).
Add tests for nroots()

We test roots of Legendre polynomial of order 64, as well as some smaller
polynomials. Besides accuracy, these tests also ensure the proper ordering of
the roots.