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
zpmlib: update version from 0.2 to 0.2.1
debian/changelog: 0.2.1-2 pkg update

This includes some changes that were missing in the original 0.2.1 pkg,
including release notes and the reported version on `$ zpm --version`.
Merge pull request #164 from larsbutler/v0.2.1-fixes

v0.2.1 fixes
Merge pull request #163 from pkit/direct_execute

Add functionality to directly execute on ZeroCloud (without deploying)
tox: add {posargs} option to test environments

This allows us to inject py.test arguments to tox in the following way:

`tox -e py27,py33 -- --collect-only -v`
Fix system.map handling in multiple places

This fixes the handling of the system.map file (job description) in
several places: project creation, deployment, and execution. It was
completely broken, evidently by
d0325d7ac043a0a3ae62541ec78daccc9cce66ab.
Merge pull request #165 from larsbutler/fix-system-map-handling

Fix system.map handling
zpm: fix the referenced issue number in a TODO

The referenced issue was not an issue; it was a pull request.
The correct issue is this one: https://github.com/zerovm/zpm/issues/46
Merge pull request #168 from larsbutler/fix-issue-num-in-comment

zpm: fix the referenced issue number in a TODO
templates: mark index.html as a template (fixes #167)

After a66f11a48e (part of #137), we only treat UI files ending in
'.tmpl' as Jinja2 templates. This meant that the index.html file was
not expanded when deploying. The authentication code thus looked like
this:

  client = new ZeroCloudClient();
      var opts = {{ auth_opts }};

which isn't syntactically valid JavaScript code.

This was apparently not discovered until now since I've mostly been
deploying a test app which provides its own UI.
templates/index: load correct system.map file

After d0325d7ac043 (part of #163), the job description template file
has the fixed name boot/system.map. It was <zapp-name>.json before.

The auto-generated JavaScript code still used the old variable name
and one could thus not execute anything with the web interface.
zpm: update docstrings and comments to match d0325d7ac0

They still referred to the <zapp-name>.json file which became
boot/system.map in d0325d7ac0. This was added with #163.
Merge pull request #169 from mgeisler/fixes

Fixes for the web interface
commands: log HTTP req/resp info

Since everything goes through swiftclient, we leverage the swiftclient
logging to do this.

This includes also a custom log filter to squelch some annoying ERROR
messages that raised if a container GET fails with a 404.

This fixes https://github.com/zerovm/zpm/issues/131.
test_commands: add a test for SwiftLogFilter
Merge pull request #171 from larsbutler/better-req-resp-logging

Better HTTP request/response logging