Proposal: inject a standalone binary for Procfile Deployment Workflows

In Deis, there are three different ways to deploy your application:

 1. Heroku Buildpack
 2. Dockerfile
 3. Docker image

For each workflow, we schedule them out by process type. The two default process types are "web" and "cmd". "web" is the process type used for workflows that follow the Heroku model. "cmd" is a special process type for docker images.

In the scheduler, we run the application's image via the command `start <process_type>`. The `cmd` process type is special, however, which the scheduler sends the command "" which means "please let the docker image determine its own default process type". This is handled by the image's CMD or ENTRYPOINT commands.

Each workflow has its own separate way of handling this `start <process_type>` command. For buildpack deployments, the image is based on [slugrunner][slugrunner] which inspects the Procfile and runs the process. For dockerfile deployments, this was handled by [supplying your own start script](http://docs.deis.io/en/latest/using_deis/using-dockerfiles/#define-process-types) which brings up the discussion on how this process is wonky. Docker image workflows have no such concept of process types and therefore do not have a way to utilize this workflow.

With this proposal, I'd like to unify the interface between all three workflows through a standalone binary which will read the Procfile and execute the process.

## What, Standalone Binary?

The binary is a tool used to handle Heroku's workflow from start to finish. However, it also supplies a command which inspects a Procfile and executes a specific process types. Some current process managers out there today include [foreman](http://ddollar.github.io/foreman/), [goreman](https://github.com/mattn/goreman/) and [herokuish](https://github.com/gliderlabs/herokuish). However, those binaries *manage* the process. We want to just read the corresponding process type and `exec` a process, taking over the PID.

## Why a Binary?

Simply put, One Binary to Rule them All. Relying on a compiled binary in the container means that we can standardize across all three platforms to better improve the workflow for scaling out by process type.

## How will this work?

For buildpack workflows, this dependency will be injected at build-time into the final docker image. When `start <process_type>` is called, we can call `/bin/binary start <process_type>`.

For Dockerfile workflows, this dependency will be injected at build-time should a Procfile be present in the application directory. For example:

```
><> ls | grep file
Procfile
Dockerfile
```

If a Procfile is present, Deis will then inject two entries into the Dockerfile and copy over a binary into the application directory:

```
cp binary $APP_DIR/
echo "COPY binary /bin/" >> $APP_DIR/Dockerfile
echo "ENTRYPOINT binary" >> $APP_DIR/Dockerfile
```

For Docker image workflows, this means that you must include this binary inside the docker image in order to handle this workflow. For example:

```
><> cat Dockerfile
FROM python:2.7
WORKDIR /app
COPY requirements.txt /app/requirements.txt
RUN pip install -r requirements.txt
COPY . /app # includes Procfile
RUN curl -sSL https://github.com/deis/procreader/releases/download/v0.0.1/procreader_linux_amd64.tar.gz | tar -xz && \
    chmod +x procreader
ENTRYPOINT procreader
```

This way, sending `start worker` to the container will execute the worker process.

# What about `deis run`?

In order for this to work, the binary must also be able to run arbitrary commands in the absence of `start <process_type>`. For example, `procreader env` is a valid command which runs `env` and displays its output, exit code etc. This is to handle `deis run` operations which the scheduler sends the raw command as the spawned process.

## Accepted Commands

The process manager must meet these requirements:

 - `start web`: runs the `web` process in the Procfile
 - `echo hi`: runs `echo hi` in the default shell

closes #2545

[slugrunner]: https://github.com/deis/deis/tree/master/builder/slugrunner