fix(builder): escape \ to avoid errors in serialization of Dockerfile
ref(controller): disable CSRF token authn/authz
ref(controller): switch to token-based authn

When pulling out CSRF tokens from the authentication requirements, we
are still relying on cookies. This is great from a CSRF attacker's
standpoint as attackers can easily `<iframe>` the site that utilizes the
API, generate a POST request and re-use the existing cookie. Using
token-based authn fixes this because there will be no existing authn
cookie in the request. With this change, we are also not vulnerable to
XSRF attacks either because we do not store a validated login cookie
in the browser (yay!).
test(integration): add client.json tests
fix(controller): standardize API datetime field format

This brings the datetime field's formatting more in line with the rest
of the platform.
fix(client): remove timezone parsing
Merge pull request #2183 from bacongobbler/api-fixes

fix(controller): standardize API datetime field format
Merge pull request #2136 from bacongobbler/remove_csrf_token

ref(controller): remove csrf token; switch to token-based authn
Merge pull request #2182 from aledbf/fix_builder_serialization_problem

fix(builder): escape \ to avoid errors in serialization of Dockerfile
fix(controller): deploy only when Build is present

In terms of 12 factor's best practices, a build and configuration is a
release. Currently, we create and deploy a new release with any change
to an application published a release. This is because we create an
initial build on app creation. With this change, no build is created on
app creation, and the first release is published to the scheduler once
the release has a build.

Other notable changes:

 - the release's image field has been removed in favour of an app's ID +
   the release's version
 - lots of the view logic has been refactored into the models
 - build and config are mandatory in Release.new

Making Build and Config mandatory in Release.new had to happen as Builds
can be nil, which caused bugs when trying to roll back to a previous
release with a nil Build. Release.rollback would call Release.new with
an older build's release info, which sometimes had a nil Build. Because
of how Release.new worked, Release.new would use it's own current Build
in the new release if the supplied build was nil, causing unintentional
behaviour.
chore(*): bump CoreOS to 472.0.0
Merge pull request #2159 from bacongobbler/premature_deploy

fix(controller): deploy only when Build is present
Merge pull request #2191 from mboersma/coreos-472

chore(*): bump CoreOS to 472.0.0