Initial commit for the asynchronous deployment of workloads.
This commit aims to accomplish asynchronous requests to salt via
three main components.

EventStore - Stores salt event related information.
JobPoller - Polls the salt master queue in a separate background
	process.  Information found is stored in the event store.
	This process is started when work.py starts and is
	signalled to stop when work.py nears completion.
MultiJob - Publishes requests to salt via the APIClient and keeps
	track of running jobs. MultiJob.wait pulls information
	from the event store which is updated by the job poller.
	MultiJob also has the ability to run a sequence of
	SaltCommands.  When a SaltCommand finishes, a check is
	performed to see if the SaltCommand is part of a chain
	and the next link in the chain is published.

Responses from salt are not validated yet and cloud-workloads
assumed every request finishes successfully.(This will change
in future commits.)

Checks still need to be made for the following:
- a job needs to be successfully published
- a job return needs to have a return for every minion involved
- a job with a return for every minion needs to have every
  minion's return validated. (Example, some states in a state.sls
  command may not have completed or may have encountered an error)
Asynchronous automated deployment and test execution via salt.

Workloads are still synchronous in the sense that one workload
must finish before another workload can start.

Workloads are asynchronous in the sense that instances are
asynchronously within the boundaries of a single workload to
reduce deployment time.

Asynchronous salt calls are achieved with three main components:
EventStore - Stores event information pulled off the salt master
	event queue.
JobPoller - Background process that continually polls the master
	event queue and places information in the event store.
MultiJob - Continually publishes salt requests until MultiJob.wait
	is called. Wait looks into the event store pulling
	until it has all the information for all published jobs or
	a timeout is reached. Wait also handles SaltCommands that
	are a sequence of salt commands. When a command in a
	sequence is identified as finished, the next command in
	the sequence is published.

Not implemented yet:
publish checking - Making sure a publish to salt is successful
job return checking - Making sure all minions in a job have a result
	and all results are 'passing'
consistent timeouts