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
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.
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.
Use Dummies when substituting in Derivative for abuse of notation.
Merge pull request #1379 from asmeurer/test_subprocess

Test subprocess
Updated docstring and small fix

1) Updated the vectorize_lambdify's docstring
2) The np.seterr in vectorized_lambdify is called even when there is no
exception.
changed the complex behaviour description in notebooks
Make the naming of dummy variables for Derivative consistent.
Merge pull request #1383 from Krastanov/headache

Fix the way that Derivatives are produced when using abuse of notation.
Merge pull request #1348 from catchmrbharath/complexValues

Complex values are discarded in plots