Consistency in run for build, deploy, et al.

## purpose
Consistency between running containers for build and deploy and possibly other scenarios in the future.

## problem 
We need consistency between the `docker run` for `build` and `docker run` for `deploy`, but in future other scenarios may also present itself. With the addition of `dokku-args` we can now mount volumes, for example, but this is currently only implemented for deploy which is problematic for the build process which is now unaware of these volumes. 

Another inconsistency which already revealed itself as well, as pointed out by #511, is the absence of a `CONTAINER` lookup which is only created at deploy and never populated when a build fails or is terminated.

## proposal
To avoid duplication and improve reusability a function wrapping the common functionality can be employed, as this merge request would suggest. To reduce cognitive friction in implementation, a compatibility with the original docker implemented call signature was sought hence the function name `docker_run`.

     $ docker_run [[call arguments] [..]] <docker image> <command> [[command arguments] [...]]
 
The method will dynamically parse arguments to deduce that everything before the global variable `$IMAGE` is considered call arguments and everything post this reference will be part and purpose of the command. This allows executing of the function `docker_run` in exactly the same familiar fashion as we would otherwise call `docker run` for this purpose with no concern for `dokku-args`, which gets injected before the image, or any future evolutions of the way a container is run. 

This was also the most logical instance at which to log the container id while effectively obfuscating the complexities/requirement from the caller which continues to receive the output as it normally would.

## possibilities
Currently only applicable to and implemented for build and deploy but may in future apply to other scenarios as well.

Another consideration would be to enhance the hook api and to separate the arguments passable to build and deploy etc. which should not obstruct this merge request nor be reason to complicate the calling signature as is proposed. 

Due to the fixed nature of the process flow identifying which process is calling can be facilitated by a simple counter persisted externally or based on other artifacts created in the `$APP` location. We could choose to simply pass this identifier along to a new `dokku-args` hook specification or create separate hooks for each all without additional requirements to the caller.