Memory/CPU limits for application containers

This PR adds the ability to restrict memory and CPU **by process type**.  Summary of changes:

 * New `Limit` domain object for tracking Memory and CPU
 * `Release` models now reference a `Limit` (which can be null for backwards-compat)
 * Abstract `Scheduler.create` is now passed `kwargs` that include memory/cpu limits broken out by proctype
 * Fleet scheduler is passed memory/cpu limits during container creation
 * HTTP API includes new `/apps/<id>/limit` endpoint for managing limits
 * New CLI commands for managing limits: `limit:set` `limit:unset` `limit:list` (modeled after `config`)

Any changes to application limits automatically roll a new release so they can take effect immediately.  This provides the best developer UX and also makes it possible to rollback limit changes.

## Developer Workflow

```console
$ deis create
Creating application... done, created example-go

$ deis pull gabrtv/example-go:latest
Creating build... done, v2

$ deis ps
=== example-go Processes

--- cmd: 
cmd.1 up (v2)

$ deis limit:set cmd=256M  # defaults to memory
Applying limits... done, v3

=== example-go Limits

--- Memory
cmd      256M

--- CPU
Unlimited

$ deis limit:set -c cmd=512  # cpu limits by CPU shares
Applying limits... done, v4

=== example-go Limits

--- Memory
cmd      256M

--- CPU
cmd      512

$ deis releases
=== example-go Releases
v4      Just now                 gabrtv changed limits for cpu
v3      Just now                 gabrtv changed limits for memory
v2      1 minute ago             gabrtv deployed gabrtv/example-go:latest
v1      1 minute ago             gabrtv created initial release
```

On the CoreOS Host:

```
core@deis-1 ~ $ docker inspect example-go_v4.cmd.1
[{
    "Args": [],
    "Config": {
        "CpuShares": 512,
        ...
        "Memory": 268435456,
```

## Test Instructions

 * To test backwards-compatibility, stand up an environment on current master
 * Deploy an application and leave it running
 * Checkout this PR and perform an in-place upgrade with `make -C controller build run` 
 * Limit the application memory with `deis limit:set cmd=1G`
 * Limit application CPU shares with `deis limit:set cmd=512`
 * Login to the CoreOS host and use `docker inspect` to confirm resource limits
 * Use `deis rollback` to rollback to a previous limit
 * Use `docker inspect` to confirm the limit was rolled back
Totally agree.  This method is a mess.  The truth is I refactored it and then pulled out the commit  at the last minute to avoid feature creep in this PR.  We should refactor it separately and write some tests for the output while we're at it.