remove the big long command command from docker::run upstart

Working with that extremely long line is very difficult. It also makes patches hard to read as you can't easily identify what changed.
It also has a significant bug in that if any arguments contained quotes, or other special characters, they'd break the command.

This change isolates each param so you can easily add and modify them. It also uses Shellwords to properly quote arguments which need it.
use a hash for docker::run env param

Hashes are the proper way of handing env vars as they accurately represent what an environment is. An environment is a list of names and values associated with each name. A name cannot be duplicated.
Using an array allows duplication. You can have ['foo=bar','foo=baz'] which is a perfectly valid array, but not valid for environment variables.
Using a hash also allows one to merge 2 hashes together and get deterministic result on collisions.

This change doesn't remove support for arrays, they still work fine.

This is also prepwork for a commit which will be following.
don't pass env vars values as arguments in docker::run upstart script

Passing env vars as command line arguments is a very significant security vulnerability. Env vars can be used for passing sensitive information such as passwords and secret keys. By putting them in command line arguments, it makes them visible to anyone who can run a simple `ps` command.
make the command argument to docker::run optional

Images can have default commands in which you don't want to specify your own
stop a docker::run upstart resource when docker stops

Previously the upstart script generated by docker::run would only stop when the box is shutting down. This leads to issues as if docker shuts down, the container is killed without upstart expecting it. This results in upstart trying to restart the container when docker isn't running.

The solution is to shut down all containers before docker stops. On shutdown, docker itself will stop, and all the containers will stop because of that.
remove `hasrestart => true` from docker upstart service

Upstart has a long history of bugs and issues with restarting services. The issue at hand here is that when an upstart script is modified, and you restart the service, it doesn't pick up the modified script. Meaning if you change any of the parameters to the 'docker' puppet class that results in modifying the docker service, they won't take effect.

When you want to pick up changes to an upstart script you have to do a full stop & start.
Remove `hasrestart => true` from docker::run upstart

This is similar to the previous commit. Performing an upstart service restart doesn't pick up changes to upstart scripts.
use $name not $title in docker::run

$title is for the user to define and should be allowed to be anything the user wants.
$name is another parameter that defaults to $title, but can be changed independently of $title, allowing user to set $title to anything, and then use $name for controlling things like the name of the init script
Fix stopping containers with docker::run upstart

The previous upstart method did not stop containers when the upstart service was stopped. This is a result of https://github.com/dotcloud/docker/pull/3240

As a workaround for the issue, on start we write the container ID to a file, and then use a post-stop script to kill that container.