There was an error in the way the sphinx documentation was
configured that prevented it from building correctly, now that
absolute imports (e.g., "from control import lti") have been changed
to relative imports (e.g., "from . import lti").

In particular, the directory "root/control" should not be added
to sys.path.  Because this directory contains an __init__.py file,
it is a Python package, and packages should never be added to the
path, or lots of strange things happen, particularly with relative
imports.  Instead, the directory "root" should be added to the
path.  This change was made in the conf.py file.

Also, the mocks for modules were fixed so that the documentation
builds even if numpy, scipy, etc are not installed.

Conflicts:
	doc/conf.py

Conflicts:
	control/ctrlutil.py

Comparisons like
    if A == None:
give a FutureWarning: comparison to `None` will result in an
elementwise object comparison in the future.

This resuits in a bunch of warnings when running nosetests, so
this commit changes these to
    if A is None:

Note that if you don't escape func(x, t, *parms) as
`func(x, t, *parms)`, then Sphinx interprets the * as *emphasis*.

Previously, at least on my machine (Mac with Anaconda),
running runtests.py gave a build error when setup.py tried to
build a local copy of the package.

It turns out this was because we were importing setuptools,
which caused problems, because the rest of the setup.py script
(which was taken from numpy) assumes we are using the numpy
version of setup(), in numpy.distutils.core

This commit removes the import of setuptools and makes setup.py
almost identical to that used in numpy.

Use setuptools instead of numpy.distutils for "setup.py test"
Note: this is apparently a bug in the version of setup.py included
with numpy ("setup.py test" doesn't work for numpy).

The travis build hangs when installing matplotlib for python 3.2
(but not 2.7 and 3.3).  This is apparently a documented issue with
matplotlib: see
    matplotlib/matplotlib#3443
    matplotlib/matplotlib#3741

Conflicts:
	control/mateqn.py

Fixes #48

The old algorithm called a general-purpose ODE integrator at each
timestep, and this could be extremely slow (hundreds of times slower
than scipy.signal.lsim).  This new algorithm evaluates the matrix
exponential once, and uses it to advance the simulation at each step.

Importantly, the old algorithm would work for variable timesteps, but
the new version assumes a fixed timestep (as does Matlab's lsim).  This
is the usual case, and it is the price one pays for increased speed.

Note that this algorithm is the same idea as the algorithm used in
scipy.signal.lsim, but the scipy version requires inverting the `A`
matrix, and thus does not work if the system has a pole at the origin.
The algorithm used here works even if there is a pole at the origin.
This commit also adds a test for this case (the double integrator).

Speed up forced_response/lsim