trigsimp traverses not only function but any Basic objects.

now this works:
In [1]: trigsimp(Subs(x, x, sin(y)**2+cos(y)**2), deep=True)
Out[1]: Subs(_x, (_x,), (1,))
In simplify call trigsimp(deep=True)
trigsimp cleanup
Run doctests in Travis CI as well
Merge pull request #1373 from certik/travis

Run doctests in Travis CI as well
Forward the `deep` kwarg to the helpers inside trigsimp.
Merge pull request #1374 from Krastanov/trigsimp_deep

Minor improvements in trigsimp
Add function run_in_subprocess_with_hash_randomization to runtests

This function will facilitate running the tests with hash randomization
enabled with a specific seed.  In order to do this, tests must be run in a
separate subprocess, because the only way to set the seed is to set the
environment variable PYTHONHASHSEED before starting Python.
Run tests and doctests in a subprocess in order to seed hash randomization

This is necessary to do because the seed for hash randomization cannot be
determined at run time unless it was explicitly set using the environment
variable PYTHONHASHSEED when the Python process started.  A new subprocess is
started only for those Python versions that support hash randomization.  Hash
randomization was added in the minor Python versions 2.6.8, 2.7.3, 3.1.5, and
3.2.3, and is enabled by default in all Python versions after and including
3.3.0.

Starting a new subprocess can be disabled by passing the --no-subprocess flag
to bin/test or bin/doctest.  This will also prevent hash randomization from
being enabled in Python 2.6, 2.7, 3.1, and 3.2, unless Python is started with
the -R flag or the environment variable PYTHONHASHSEED is set.

To run the tests with a specific random hash seed, use

$ PYTHONHASHSEED=42 python setup.py test
Fix return value of _doctest
Make run_in_subprocess_with_hash_randomization() return False instead of None

Sometimes subprocess.call() can return None, so that value is already used.
Add a note about architecture and hash randomization to the test() docstring
Don't sort the elements of a FiniteSet.

This reduces the performance of the constructor of FiniteSet and is not
compliant with the definition of a set in the first place.
Reset PYTHONHASHSEED after running the tests or doctests

This way, it will be as it was for the outer Python process (the one that
creates the subprocess).  Without this, running more than one test (e.g., the
tests and then the doctests) would not work after the first one, because the
later ones would think that the seed was already set and not spawn a
subprocess.

Note that as a result of this, each test/doctest will have a separate hash
seed.
Make str.py and latex.py print FiniteSet in a sorted way.

The printer in pretty.py already sorts FiniteSet's, therefore no changes
are necessary in that printer.
Explicitly define FiniteSet._hashable_content.

Previously, FiniteSet would rely on Basic._hashable_content, which
returns .args.  FiniteSet would construct .args by frozensetting the
arguments it would get.  Apparently, this does not guarantee that
FiniteSet's constructed from the same elements will eventually have the
same .args, i.e., the order may change.  This commit makes FiniteSet
return the frozenset of its original args, wrapped in a tuple.  This
assures that two FiniteSet's with the same elements are equal (because
the corresponding frozenset's are equal), and keeps _hashable_content a
tuple.
Sort FiniteSet elements when computing the complement.

FiniteSet._complement used to rely on the fact that .args was previously
sorted.  Now the sorting has to be done explicitly.
Complex values are discarded in plots

If a complex value is encountered while plotting, it is masked
using a numpy masked array and the complex value not plotted in
the plot.
refractored experimental_lambdify
Fix the way that Derivatives are produced when using abuse of notation.

Pull Request #460 introduced support for a handy abuse of notation, however it
disregarded the convention for constructing `Subs(Derivative(...))` objects
causing serious inconsistencies:

 - this does not work anymore:

```
In [1]: f(g(x)).diff(x).subs(g, Lambda(x, 2*x))
Error
```

 - these results are inconsistent:

```
In [6]: Derivative(f(x), x).subs(x, 2*x)
Out[6]: Subs(Derivative(f(_x), _x), (_x,), (2*x,))

In [7]: Derivative(f(x), x).subs(x, sin(x))
Out[7]: Derivative(f(sin(x)), sin(x))
```

These are fixed in the present commit.

There was also a conflicting definition of "derivation wrt function" in the
docstring that was partially removed. The main source of the inconsistency was
the confusion in calling `f(x)` a function when only `f` is a function. This
does not permit a real distinction between `f(x)` and `2*x` which was claimed
in the docstring.