Setup .env file management using capistrano-env
Load .env file in `config/boot.rb` [ci skip]

Part of the ideal 12 Factor[1] setup is loading the environment
variables prior to starting the application a la the `foreman` gem.
While the 12 Factor manifesto doesn't say this methodology is required,
it avoids mutating the `ENV` in the running process making it easy to
avoid potentially subtle bugs where code fails due to the `ENV` not
being loaded early enough or having to setup complicated /
unconventional load orders to ensure the `ENV` is loaded before all
other code that depends on it is loaded.

Using MIT Touchstone requires use of shibboleth[2], which requires using
the Apache webserver. In order for the Rails application to use
shibboleth to sign in users, it needs access to Apache environment
variables[3]. The only Rack web server that provides this functionality
is Phusion Passenger[4]. While it is possible to use HTTP headers to
communicate information provided by Shibboleth, it is strongly
discouraged due to security concerns.

Passenger's solution for loading the `ENV` before starting the
application is through Apache's `SetEnv` and `PassEnv` directives[4].
This requires editing Apache XML conf files and restarting/reloading
Apache anytime `ENV` variables need to be changed. This requires root
access and is difficult to do programatically without a well-managed
Chef or Puppet deployment[6].  It also does not help with loading `ENV`
variables for other processes such as `sidekiq`.

Given the set of requirements and limitations, `config/boot.rb` is the
ideal place to load the `ENV` since it:

1. Ensures both web, background and console processes have the same
   `ENV` loaded.
2. Occurs just after `bundler` is setup, but before any gems listed in
   the `Gemfile` are loaded.  This solves modifying the `ENV` before any
   application code needs it.  If any code that needs to be configured
   by the `ENV` occurs in `config.ru` or `config/environment.rb`[7], the
   location `Dotenv.load!` is called needs to be changed or `config.ru`
   / `config/environment.rb` need to be modified.

`Dotenv.load` is used over `Dotenv.load!`, deferring to where the `ENV`
is read from to ensure the value is present (i.e. via `Hash#fetch`
without a fallback).

This strategy also maintains dev/prod parity by ensuring we load the
.env file in a consistent manner in development and in production. To
maintian parity with the Apache config strategy, the development
environment need to have apache running.

Dev/prod parity still needs to be resolved around signing in with
shibboleth, either via enabling with a feature toggle or reproducing the
functionality in development via a service such as testshib.org.

[1] http://12factor.net
[2] https://wiki.shibboleth.net/confluence/display/SHIB2/Home
[3] https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPEnableApplication#NativeSPEnableApplication-Environment/HeaderVariables
[4] https://www.phusionpassenger.com/
[5] http://httpd.apache.org/docs/2.4/mod/mod_env.html
[6] The current goal is to manage deploys and deployment configuration
    via capistrano
[7] `BUNDLE_GEMFILE` cannot be changed by the .env file using this
    method. There isn't a need for this so it can safely be ignored.
Merge pull request #20 from ecbypi/capistrano-env

Setup ENV variable management and loading