setup: use setuptools over distutils

Distutils is the stdlib packaging tool. However, setuptools is the
preferred tool for projects that define dependencies:

  https://python-packaging-user-guide.readthedocs.org/en/latest/current.html

Setuptools is a dependency of virtualenv and pip, so most developers
will have it installed.

Using setuptools means that the dependencies will be automatically
installed when running 'python setup.py install'.

This is important for the Read The Docs build since it installs the
project like that instead of using pip. So the documentation build was
broken since the autodoc Sphinx directive fails when our dependencies
are missing.

If setuptools is not present, a warning is printed and the
installation/packaging can continue.
Merge pull request #153 from mgeisler/setuptools

setup: use setuptools over distutils
test_zpm: group tests for _deploy_zapp

This groups all of the tests for zpmlib.zpm._deploy_zapp into the same
test class. This is for better consistency and so we don't have related
tests scattered everywhere.
test_zpm: uniform naming for _deploy_zapp tests
test_zpm: add more checks to _deploy_zapp tests
test_zpm: add mock response to conn.get_container
zpm: add container checks before deploying zapp

Swift has eventual consistency, so we don't want to risk overwriting any
files. This can cause strange bugs.

The rules are:

    if container exists:
      if container is empty:
        deploy
      else:
        error: container must be empty
    else:
      container doesn't exist; create it
test_zpm: tests for _deploy_zapp container checks
Merge pull request #156 from larsbutler/deploy-container-mgmt

Better management of containers on `zpm deploy`
set correct content type for zapp files

*.zapp file is `application/x-tar`
now it will be set correctly on `deploy`
will also force `application/json` for job description json file
Merge pull request #155 from pkit/content_type

set correct content type for zapp files
setup: remove version from swiftclient dep

As far as we know, there's no particular reason to pin zpm to depend on
python-swiftclient>=2.1.0. Any version should suit our purposes.
Merge pull request #159 from larsbutler/fix-swiftclient-dep-version

setup: remove version from swiftclient dep
debian/changelog: update for the 0.2 release pkg

This is meant for packaging the 0.2 tag
(81505fade42134e249cfe410125097820cc8e8b5).
debian: 0.2.1-1 package update

Includes all of the fairly minor bugfixes since 0.2. Also includes the
python-swiftclient dependency (which wasn't present in the package
before).
Merge pull request #162 from larsbutler/deb-pkg-0.2.1

Debian package for 0.2.1
improve zapp format

according to [zerocloud/doc/Requests.md](https://github.com/zerovm/zerocloud/blob/swift-2.0/doc/Requests.md#post-a-zerovm-image-file)
the tar image should include `boot/system.map` file to become executable in Zerocloud

renaming `<zapp name>.json` to `boot/system.map` solves that incompatibility
it can be used to directly execute zapps on zerocloud clusters without deploying them first
fix _post_job

_post_job used `Accept` header which is not needed
it also used unconfigurable `Content-Type` header, although jobs can be of various content types
add option to execute zapp without deploy

now `execute` command has an optional `--container` argument, rather than required
if `zpm execute zapp_path.zapp` is invoked the zapp will be executed directly without deploying
if `zpm deploy zapp_path.zapp --execute` is invoked zapp will be deployed and then executed
if `zpm execute zapp_path.zapp --container container_name` is invoked an already deployed zapp will be executed

I think the last one should become `zpm execute swift://./container_name/zapp_name.zapp` instead, but lets leave it for now
README: add release notes for 0.2.1