Extract feeder#dose to a Doser method object

The dose action is a bit complicated for a controller action.

Refactor it by extracting to its own object which can manage the dosing
process.  Break apart the method into helpers so that each helper method
is brief, focussed, and at a single level of abstraction.

Split the asynchronisity into a separate API entry point to facilitate
testing within a single transaction.  (Transactional fixtures are
incompatible with multithreaded tests.)
Add a simple spec to Dose to replace pending placeholder
Remove Doser's dependency on a Rails environment

Doser requires a full rails environment for testing because it
creates a Dose ActiveRecord model.

Pass in the active record class as a factory object.  This flex
point allows a mock to be easily injected during testing.  This
in turn allows the spec to run without loading Rails and without
hitting the database.  It also improves code quality by reducing
coupling between the Doser and Rails.
Reduce sleep times in Doser spec

Now that the Doser spec runs without ActiveRecord, the length of
sleep time has become the limiting factor on runtime.

Reduce all the timings by 10x for a 5x reduction in spec runtime.
Move non-transactional examples to their own describe block

We're currently running all the feeder specs without transactional
fixtures, even though it needn't be that way.  Also, we're repeating the
Dose.destory_all cleanup.

Create a nested describe block to limit scope of disabled transactional
fixtures move destroy_all to a before block.
Allow an in-progress dose to be cancelled

Once a dose is in progress, there is currently no way to modify or
stop it, short of restarting the server.  And even then, there is
no guarantee that all pumps will be left in the "off" state.  Even
if the "Starve" action is invoked, the pump could still be switched
back on by the background thread.

Allow an in-progress dose to be cancelled:

* Change the "Completed at" column on the index page to a Status column
* Add "cancel" link under Status for an in-progress dose
* Process the "cancel" action by cancelling a dose
* Add a cancelled_at column to the doses table to record the
  cancellation
* Stash away the thread when dosing and kill when cancelling
Extract cancel logic from FeederController

The FeederController is mostly insulated from the nitty gritty
details of dosing.  But its new cancel action contains many
low-level details about dosing.

Extract the cancel action's detials to a new Doser.cancel
method.  Move dose creation out of the contstructor, since
the doser doesn't always do that.  Adjust unit level spec
accordingly.
Apply Twitter Bootstrap more thoroughly for visual appeal

Twitter Bootstrap is installed, but the views don't make much
use of its special class-based library.

Bootstrapify the forms and layout.  Add placeholder navigation and
footer.  Remove uneeded .min files; Rails should be able to minify
well enough.  And fix the inclusion order of bootstrap-responsive
to fix margins in narrow windows.
Add unit-level spec for cancellation

We have feature-level coverage for dose cancellation, but that
won't tell us very well which part is broken when something breaks.

Add an isolated unit-level spec for cancellation.
Create attr_reader for @dose_class for uniform access
Update .rvmrc to .ruby-version to avoid warning

The older .rvmrc file has security issues and is deprecated in favor
of .ruby-version.

Switch to the new, more secure way of specifying a ruby verison.
Capture dosing exceptions in the logs for diagnostic purposes

Currently, if an error occurs while dosing, it will typically be in
another thread, where the message and stack trace will not be captured.

Handle exceptions in the background threads by logging exceptions so
that issues can be diagnosed.
Add failed state and switch fto separate state column

We need to add a state: failed.  This allows us to show the user when a
dose has failed rather than only logging it to the application log file.

Alter the doses table to store the state and finished timestamp
separately rather than one timestamp per ending state, so that we don't
have three ending state timestamps.  Update these new columns with
timestamp and failed state when handling a dosing error.