Batch Mode (REPL)

This provides the ability to start the razor CLI up in a long running
process and issue commands to it via stdin. Each line sent to stdin will
be read and parsed as if it were sent via the shell.

Combining --batch with the --webcommand option allows us to start up a
pool of long running razor commands to process incoming requests. This
should improve razor's performance when under heavy load.
Razor API Executable Pool

This creates a pool of Razor executables that can be used by the API.
Razor is started in batch mode and the commands are sent via stdin. This
has two effects:

  1. Resource consumed by the razor executable itself are confined. It
     will never be more than one executable per cpu. This helps prevent
     'stacking' and eventually OOM/singularity situations.
  2. The API can now respond very quickly since the disk access is now
     minimized. Time is no longer wasted spinning up ruby just to tear
     it back down again.

This particular solution to the 20K problem is only possible because of
the clever and provident design of the CLI + API. Kudos.

Fixes #265
Image Service IO Pool

When a large number of requests is received the Image Service can
exhaust the IO of potential of the system. Without some kind of
throttling, it can spawn a large number of simulaneous IO requests which
then cause resource contention issues to drive overall IO performance
down.

The IO pool is limited to 5 simultaneous IO streams. When the systems IO
is not saturated this has very little impact on the overall IO
performance. When the system is IO constrained it helps keep the
existing IO operations progressing.