Add support for Tox (http://tox.testrun.org/) and Travis CI (http://about.travis-ci.org/)

Remove compile directory if it exists before downloading source

Fix annoying behavior where, after a failed compilation, it is needed to run buildout to have the compile-directory removed but have an error message, then run it again to try to compile again.

Add tox.ini for Tox (http://tox.testrun.org). MANIFEST.in also required to make sure all needed docs and tests get into the sdist.

Fixing Recipe.call_script on Windows

A very small ammendment to the --prefix argument of ./configure

If the script was r'C:\someDirectory\someFile.py:someFunction', splitting it would raise an exception
The correct way to spli the filename and the callable would be to rsplit(':', 1)

The call signature for the hook scripts was changed by adding a third
parameter which is a dictionary containing the environment variables copied
from ``os.environ`` and augmented with the environment overrides from the
part configuration.

Existing hook scripts that accept only two arguments continue to work but
reading ``os.environ`` directly will not contain the overridden values.

Python versions prior to 2.6 have an issue clearing the environment variables
using ``os.environ.clear()`` (See http://bugs.python.org/issue3227).

Instead of modifying ``os.environ`` directly we use the ``subprocess``
module to run the commands in child processes which are given an explicit
environment which is a copy of the current ``os.environ`` augmented with
the per-part overrides.

See https://github.com/hexagonit/hexagonit.recipe.cmmi/issues/issue/1/#issue/1/comment/605362
for details.

Due to this change the hook scripts no longer have the augmented environment.
They can still access the buildout configuration to read the overrides but
need to do this manually.

See http://github.com/hexagonit/hexagonit.recipe.cmmi/issues#issue/1

After a failed attempt, if the user removes the __compile directory
but leaves the target directory untouched, and re-runs the buildout,
an OSError should not be raised.

When installation fails, the working directory is left in place: further
calls to cmmi recipe with the same arguments should not raise an
OSError.
Let the download recipe handle the error, and print a friendly error.

This change makes sure that the working directory is restored to the location
it was before running the recipe, regardless whether the execution of the
recipe is successful or not.

Thanks to Jonathan Ballet for pointing out this problem.