Restart Wang's algorithm with appropriate polynomial (#3256)
Staging of the new differential_geometry module.

This module is based on "Functional Differential Geometry" by Sussman and
Wisdom.

Import:
-------
It is not automatically imported by `from sympy import *`. To import it use
`import sympy.differential_geometry`.

Structure:
----------

The first patch brings the basic `Manifold` and `Patch` classes which are not
much more than containers for objects defined on the Manifold.

Each `Patch` can define a number of `CoordSystem` objects which contain all the
logic necessary for coordinate transformations.

`Point` instances can be defined using coordinates in a `CoordSystem`.

`ScalarField` objects can be defined. They take a point and return a scalar.

`VectorField` represents an operator on `ScalarField` (a directional
derivative).

Rudimentary docstrings are provided.

Predefined Manifolds:
---------------------

The R2 manifold is predefined in order to facilitate work on this manifold.
To import it use `from sympy.differential_geometry.Rn import R2, R2_r, R2_p`.
R2 is the manifold and R2_r and R2_p are the rectangular and polar
`CoordSystem` instances.

Other predefined manifolds will be supplied also.

Tests:
------

Test with complete coverage are provided. The examples from "Functional
Differential Geometry" are also provided as tests.

The only part that is not tested is unfinished functionality related to the
connections between coordinate systems.

The test_args.py test that check whether the args are instances of Basic are
XFAILed at the moment.
Mark coordinate-dependent attributes in differential_geometry as private.

An underscore was appended to all attributes that are coordinate-dependent.
Addtional docstrings in the differential geometry module.

Doctests were slightly updated. Explicit mention about the effect of different
coordinate system choices was added.
Work on itegral curves in the differential geometry module.

Two new functions were added to the differential geometry module that deal with
integral curves. Tests for these functions are supplied.

Integral curves are inherently represented in coordinate dependent way because
there is no coordinate independent way to present movement from point to point
on a general manifold (i.e. there is no such thing as difference between two
points).

The first function is `intcurve_series`. It produces the series expantion of an
integral curve when given the starting point and the coordinate system in which
it must work.

Specify a starting point and a vector field:
>>> start_point = R2_r.point([x, y])
>>> vector_field = R2_r.d_dx

Calculate the series:
>>> series = intcurve_series(vector_field, t, start_point, n=3)
>>> series[0]
[x]
[y]
>>> series[1]
[t]
[0]
>>> series[2]
[0]
[0]

The second function is `intcurve_diffequ` that works in the same way as the
first one, however it returns a system of differential equations describing the
integral curve.

Specify a starting point and a vector field:
>>> start_point = R2_r.point([1, 0])
>>> vector_field = -R2.y*R2.d_dx + R2.x*R2.d_dy

Get the equation:
>>> equations, init_cond = intcurve_diffequ(vector_field, t, start_point)
>>> equations
[f_1(t) + Derivative(f_0(t), t), -f_0(t) + Derivative(f_1(t), t)]
>>> init_cond
[f_0(0) - 1, f_1(0)]
has() refactoring: extract single pattern base case into ._has()

+ Simplify common case, when the pattern is an ordinary Basic instance.
Move preorder_traversal to sympy.core.basic

This will allow it to be used everywhere, and in particular in the core.
Use preorder_traversal in Basic._has()
Simplify Basic.atoms() and use preorder_traversal()
Use preorder_traversal() in Basic.find()
Use preorder_traversal in Basic.count()

* Extract query preprocessing from Basic.find() into _make_find_query(),
  to allow Basic.count() to use it directly.
Simplify code in Basic._has()

* iterative was always True
* the argument of _ncsplit is always an Add or Mul
Basic._has: remove inner function _match()

* .has() shouldn't support objects with non-Basic args, like
Tuple(sin, cos) (cf. issue 2070).
Simplify inner functions in Basic._has()
Basic.has(): move handling of AssocOps to AssocOp

Instead of hardcoding the matching function inside Basic,
pattern._has_matcher() is now used, thus removing a dependency
of Basic on its subclasses.
Fix (x*y).has(x+y) and similar cases.
preserve ability to test for bool and Function in Tuple
Bring the SparseMatrix constructor in compliance with the Matrix class

The SparceMatrix constructor was duplicating code and some of the semantics
were different from those imposed by MatrixBase. Now the
_handle_creation_inputs is used for all inputs for wich we do not have special
sparce logic.
bin/use2to3: Handle extension-less files correctly

The use2to3 tool previously only considered files ending in .py or .txt
to pass to 2to3. However, scripts have no extension and weren't being
passed to 2to3. This also required a hack when fixing the shebang lines.
Handle this by making a list of relevant files with no extension and
checking if the modified file is in it.
bin/use2to3: Use git ls-files

Currently, the script traverses the whole source and grabs all .py
files, skipping a few specific directories. If the user has some extra
Python files around they might crash 2to3; also, all files will be
copied to a new directory and this is not optimal. Instead, use
"git ls-files" to get a list of all the files tracked by git and only
copy those. The "old" way is removed.

Fixes issue 2673. Note that this approach is not faster than the old
one.