Add mock for EvalIn (middleware)

DO NOT DEPLOY THIS!
-------------------

It has one piece missing (prod middleware), but my family just showed up
and now I have to go entertain them for a bit, won't get to come back
and work on this for probably another 6 hours or so.

Things this adds
----------------

* Update dependency on eval.in to point at the git repo I just pushed
  Will try to actually release this soon, but not completely sure yet
  that I like it, need to let it sit in my brain for a bit so I don't
  go changing interfaces a repeatedly in a short period of time.
  This version makes a mock object available. We will inject either
  the real one or the mock in a Rack middleware, based on environment.
* The app's `get '/run'` uses an `eval_in` that it gets from the `env`
  rather than a hard dependency on the `EvalIn` class.
* Middleware for dev environment in config.ru
  this one evaluates the code on your local computer
  it assumes you have a binary named 'ruby'.
  This will allow us to get the same effect locally as if
  we were really hitting the service, but without that cost.
  I seem to be really apprehensive about doing this,
  guess I'm expecting them to eventually get annoyed with us
  and cut us off, making MOI not work at all. Probably I need
  to look into Docker to see if I can make my own service to offer
  evaluation functionality. Pretty sure that I pinged Charlie
  at one point to ask if there was an endpoint that just did evaluation
  and didn't do persistence so that I wouldn't feel so bad about
  spamming the codepad and filling up his hard drive with code
  that doesn't need persistence, just evaluation.
* Middleware for test environment in features/support/our_helpers.rb
  This one expects a response to have been defined in a previous
  cucumber step and then returns that response directly without
  any evaluation.
* Remove `OurHelpers#server`, it was misnamed, it was really the app.
  But now that we added the middleware, the app is the whole thing.
* Expose `OurHelpers#app` I don't know if there is a word for this kind
  of thing, but it's a middleware around an app (these are really just
  linked lists).
* Fix the environment resetting in features/support/env.rb
  This is the reason the tests were so flaky. The tests are still bad,
  but should at least be reliable now.
* In the step defs, inject the app instead of stubbing it.
* `Given 'I have a git repo'` uses `FsHelpers#make_upstream_repo`
  instead of trying to do it on its own. This was failing when we
  would reset the data directories, because it assumed the directory
  it wanted to work in was available (but leaving it available was
  causing tests to interfere with each other). The builtin one is better
  because it basically does a `mkdir -p` before trying to work in the dir.
* Update expectations to match the defaults that `FsHelpers#make_upstream_repo`
  sets, rather than the ones from the previous repository.
* Base the `Then "my endpoint has been persisted to the server's json file"`
  off of the repopath instead of the SHA, since currently the SHA is going
  to be `master`, which is not particularly confidence inspiring.

Things still missing
--------------------

* The production middleware to set the real `EvalIn` into the `env` hash.
  This is why we can't deploy this. But I gots ta go now! and wanted to
  make this available.
* EvalIn should release its version, right now we're using the one
  from the git repository itself.

Where to go from here
---------------------

* Can we delete the shitty stub lib I wrote? I think it was only
  being used to stub the response on EvalIn, but now that we are
  injecting it, we don't need such brutish measures.
* Many of the things that are making this difficult (singleton objects)
  should be injected in middlewares. I think this is just the manifest
  and any relevant directories.
* Add the prod middleware
* Deploy this