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
Yes, though I tried hard to restrain myself to just what was needed for Memory/CPU.  I have a follow-on PR in mind for cleaning up the scheduler code in general -- including using a proper templating system for the systemd units!