Python opinionation for zpm

This patch add several new things:

- `zpm new --template <template>`: Templates are now explicit. The default template was python-specifc anyway, and this change allows for extension. (The next template I plan to implement is one for zapps written in C.)
- `zapp.yaml` files have a new optional directive: `project_type`. If none is specified, the default is assumed to be `python`. The `project_type` is the same as the `--template` chosen with `zpm new`.
  - Older `zapp.yaml` files with no `project_type` are assumed to be `python` projects. This may cause some headaches for a few users (who might be doing C), but shouldn't be a problem for most.
- `zapp.yaml` files have a new optional directive: `depends`. `depends` is a list of 3rd party python package names. This is a convenience for zapp developers who want to include pure python libraries which are not in the python standard library. When `zpm bundle` is called, these depends are fetched (using `pip`) and cached in the `.zapp` directory (located in the working directory containing the `zapp.yaml`). Dependency fetching and caching are handled using `tox`. This is a bit quick-n-dirty, but it seems to work well enough for the moment. The advantages provided by `tox` could also enable new commands, like `zpm test` (similar to `go test` for the Go language).
- `zpm bundle --refresh-deps`: Since python dependencies are locally cached (so time is not wasted fetching them every time `zpm bundle` is called), a user may want to refresh those dependencies, particularly when the `depends` section is updated.

Known issues:

- For some third party python libraries, like [BitVector](https://pypi.python.org/pypi/BitVector/3.3.2), the `tox`/`pip`-based mechanism will encounter problems fetching the package. It will give an error about fetching externally, and will suggest to use `pip install --allow-external BitVector BitVector` to install this dependency. Some hacking of the `tox.ini` created by `zpm new --template=python` can work around this.
- For a given dependency `foo`, `zpm bundle` will install the dep and pack it into the zapp file. It does this by looking for either a module (`foo.py`) or a package (`foo/`) and adding it to the archive. In the case of a package like [glibc](https://pypi.python.org/pypi/glibc/0.6), there are multiple source modules/packages to include: https://github.com/zyga/python-glibc/blob/1097a1e5d1e243f08a4872fdb0f088c3c019bc12/setup.py#L35-36. `zpm bundle` is naïve and only looks for packages/modules bearing the name of the top-level python package. So in this case, `zpm bundle` will miss the `pyglibc` package.
  - The semantics of the `depends` directive should be amended in the following way:
```yaml
depends: [
  "pngcanvas",
  ["glibc", "pyglibc"]
]
```
  This indicates to `zpm bundle` to install and cache `glibc` from PyPI, and then bundle the modules/packages `glibc` as well a `pyglibc`. This can also be used to package further dependencies which may be required by a library. For example, if a package `foo` depends on `bar`, and `bar` gets installed when we fetch `foo`, we can do this to include both in the zapp:
```yaml
depends: [
  "pngcanvas",
  ["foo", "bar"]
]
```