split up configparser prepare_* into separate func

configparser prepare_zerovm_files() was too specific for standalone case
made it more generic and added 3 specific funcs:

- prepare_for_standalone()
- prepare_for_daemon()
- prepare_for_forked()

now different set of manifest, nvram and other support files is generated
depending on what type of zerovm execution is required

it also fixes inconsistency in handling manifest for the case where daemon was dead for some reason and restarted from middleware after unsuccessful socket connect
Merge pull request #33 from pkit/proxy_fixes

split up configparser prepare_* into separate func
added new configuration options to docs

all the new and advanced configuration options for the middlewares are added to Configuration.md
Merge pull request #34 from pkit/minor_fixes

added new configuration options to docs
some more Configuration.md doc changes
Merge pull request #35 from pkit/minor_fixes

some more Configuration.md doc changes
changed the /dev/image channel type to 3

the /dev/image default channel type was always 1 (append-only channel)
but with recent developments in zrt and future introduction of real append-only channels it should be moved to 3 (randomly readable)
Merge pull request #36 from pkit/config_fixes

changed the /dev/image channel type to 3
fixed bug inroduced in c567b10

swift:// url relative path feature was not tested enough
added proper tests and fixed bugs
Merge pull request #37 from pkit/proxy_fixes2

fixed bug inroduced in c567b10
added new servlet job feature: attach

`attach` makes it possible to attach a job (ZeroVM session) to one of the devices specified in json job config.
It means that the executable and all other objects will be copied to the node that contains that object, and the code will be executed on that node.
Obviously it does make sense only if the device path is a Swift one.

Documentation was also fixed to reflect the new `attach` property.
Merge pull request #39 from pkit/feature_attach

added new servlet job feature: attach
deprecated "file_list" and "device" keywords

In the servlet job config file replaced:

- `"file_list": []` with `"devices": []`
- `file_list[]['device']` with `devices[]['name']`

The backword compatibility is maintained, but the old keyword names are marked as deprecated in docs
requirements: add URL for Swift

For some reason, the latest Swift version on PyPI is 1.0.2. However,
the developer do publish pip-installable tarballs on Launchpad:

  https://launchpad.net/swift/

We can instruct Pip to look there with the --find-links flag, and this
flag can be embedded in a requirements.txt file.

This will solve https://github.com/zerovm/zvm-jenkins/issues/22.
tox: remove special install_command

This no longer needs to be customized after we added --find-links to
the requirements.txt file.
Merge pull request #41 from mgeisler/swift-find-link

Add `--find-links` for Swift
Merge pull request #40 from pkit/feature_new_config

deprecated "file_list" and "device" keywords
implement deferred response for longer jobs

introducing a new header `x-zerovm-deferred`
can be `never`, 'auto` or `always`

`never` (default behavior)
will support the legacy use case
which means that results of any jobs will be returned in the response body and headers, regardless of how much time the response will take
if one of the timeouts fires up, the results of a job my be lost

`always`
results will always be deferred, which means that after the job was successfully submitted to object servers the response will be immediately returned to user
the response body will contain Swift URL of the object that user needs to poll, and the results will appear in that object
Swift URL will be of the form: `swift://account/container/object`

If user submitted a POST request to `/v1/a1/c1/o1` the deffred response results will appear under `swift://a1/c1/o1`
If submitted to `/v1/a` (default case) the deffered object URL will be auto-generated.

`auto`
if there is `interactive_timeout` configuration variable configured for proxyquery middleware the value of that variable will be used for the timeout
if response will arrive before `interactive_timeout` the response data and headers will be sent immediately to the user
if `interactive_timeout` passes then deferred object URL will be sent to user in the response body and the results will be placed under that object

if `interactive_timeout` is not configured the value will be the same as `node_timeout` and the behavior of `auto` will be the same as `never`

if the response is deferred the `swift://account/container/object` URL will contain the body of the response
another object will be also created `swift://account/container/object.headers` and it will contain all the headers of the response (serialized to JSON)

if your job produses a lot of headers and it's hard to manage them
you can set the job to `always` and then headers will be placed into Swift object that can be parsed and queried separately
pep8 formatting fixes
Merge pull request #42 from pkit/deferred_response

implement deferred response for longer jobs