Switch to cedarish cedar-14 stack image
Use flynn buildpack installer

The flynn buildpack installer allows installing a specific version of a buildpack giving more control over the final buildstep environment.

See https://github.com/flynn/flynn/blob/master/slugbuilder/builder/install-buildpack for the upstream source
Modernize the builder

* Uses the buildpack installer for custom buildpacks
* Uses helpers to format the output
* Uses the environment variables for the start & exec commands
Remove old buildchain
Update Authors, License and add changelog
Remove preinstalled custom buildpacks
Add ENV_DIR support

Prepare buildstep to support the ENV_DIR feature that allows usinge the configuration variables during the compile phase. This change will need a change to dokku to put split the ENV file and insert it into the container as separate files.

This also makes the sourcing of the files in the .profile.d directory only take `*.sh` into consideration, matching the way that Heroku works.

See https://devcenter.heroku.com/articles/buildpack-api#bin-compile-usage for details on the ENV_DIR feature.

This implements #101 but also writes the config_vars to `config_vars.sh` so that defaults from the buildpacks get honored. That should be OK since the config_vars don't overwrite existing environment variables anymore.

This commit is a combination of #99, #100 and #101 adjusted slightly for the new builder structure.
Source profile.d for interactive shell
Run as non-root user

Generate a random user on each deploy and run the compile step as well as the final application with this restricted account. This should solve the problems with the permissions in the PHP buildpack and the Bundler warning in the ruby buildpack.

References:
  * #88 - security?
  * #98 - Run apps as non-root user, take 2
  * #42 - Allow apps to run without root
Run process(es) under supervision

This runs the processes defined in a Procfile using the daemontools supervisor. This has some advantages:

  * Multiple processes can be started
  * Restarting failed processes
  * Logfile rotation (defaults to 10 files of 1MB each)

Defining which processes get started and how many of each is determined by the parameter /start is being called with.

Step one is extracting a `Procfile` from `.release` if none exists. In this case `/start` defaults to running the `web` process. Otherwise it defaults to starting one of each process defined in the `Procfile`.

If `/start` is being called with a process name like `web` as parameter only that process will be started.

If `/start` is being called with a `formation` like `web=1,worker=2,clock=1` it will start 1 web, 2 worker and 1 clock process. Processes not named in the formation wont get started.

Currently starting more than 1 web process will almost certainly will wreak havoc on your container since you only have a single port to listen on.

The exporter is based in large part on [Foreman](https://github.com/ddollar/foreman) and modified to fit the needs of this special application.