Update trackpy's version constraints

[caspervdw]

Our current setup.py lists the following version constraints:

    install_requires = ['numpy>=1.9', 'scipy>=0.14',
                        'pandas>=0.15', 'pyyaml', 'matplotlib'],
    python_requires=">=3.5",

On the python timescale, these versions are ancient: end 2014.

• Python 3.5 has reached its end of life as of Sept 2020 (https://www.python.org/dev/peps/pep-0478/)

• Currently, the earliest supported numpy is 1.17 (https://numpy.org/neps/nep-0029-deprecation_policy.html)

  In https://github.com/soft-matter/trackpy/blob/master/.github/workflows/test-pip.yml I have been much more conservative than these official recommendations (Python 3.5, Numpy 1.13). I think that is a good thing, as trackpy is used by researchers which tend to be less on the forefront with upgrading their scripts. I am sure there also plenty Py2.7 scripts around.

We do have to draw a line somewhere. What do you think @tacaswell @danielballan @nkeim ? Just bump the dependencies to the first ones I happened to test with?

And maybe we should do something with the extras_require to list optional dependencies (together with their version constraints) explicitly (https://setuptools.readthedocs.io/en/latest/userguide/dependency_management.html#optional-dependencies), like numba and (py)tables.

[nkeim]

Thanks @caspervdw for leading this important work!

We do indeed have to draw the line and I think that consistent with NEP 29, ~4 years is a good time horizon for backwards compatibility. In an academic lab, 4 years means that a student can probably do a Ph.D. project and update specific components as desired, without ever having to redo their whole Python environment.

We also have the advantage that the trackpy v0.4 series has proven to be very mature, and there are no "breakthrough" features planned for v0.5.

I support dropping NumPy before 1.17, Python 3.5 and maybe even Python 3.6 (unless we're planning to release v0.5 next week :).

I'm also fine with adopting the NEP 29 suggested language about backwards compatibility.

I think that extras_require is nice. In practice, though, I'm not sure it would be very useful, since pip is not the best way to install some of those optional dependencies (which seem to be: pims, numba, tables, pillow).

At minimum, though, it would be great to include at least two extras_require features:

• tests: py.test
• doc: sphinx, pypandoc, sphinx_bootstrap_theme, nbconvert