Change the default value for the tmpdir option to use mktmpdir (a subdirectory within /tmp like
/tmp/shrimp20131120-28880-1bll5ur) instead of just saving everything directly under /tmp
(Dir.tmpdir).

This way you can easily list or delete all shrimp-generated temp files with something like:

    rm -r /tmp/shrimp*
Rename fire_phantom to render_pdf to be more consistent with other methods like render_as_pdf and
already_rendered? that use the verb "render".
Add log_render_pdf_start and log_render_pdf_completion, which give useful debugging information if
config.debug is true.
Merge the options that were passed in to the middleware with the options configured in
Shrimp.config, so that you can override an option from Shrimp.config by passing in a different value
to the middleware.
Remove duplication between run and run! methods.

Change run! to simply call run and then check the @error status afterwards.
Add page_load_error and page_load_status_code methods to Phantom.
Add full response details to what rasterize.js outputs so that we can get the redirect URL, etc.

Add response and redirect_to methods to Phantom to make it easy to get at that data.

Add a .chomp to @result to get rid of the extra newline at the end.
Add a simpler middleware, SynchronousMiddleware, that runs the phantomjs command synchronously and
doesn't use any of the fancy polling that Shrimp::Middleware uses.  It also avoids showing the user
an ugly "Preparing pdf..." page, which doesn't even go away after the PDF file has been downloaded.

The caveat is that you must make sure that your web server is able to process any number of
concurrent requests (or at least enough concurrent requests that you aren't worried).  If your web
server reaches its concurrency limit and then receives a request for a .pdf resource, then when
phantomjs attempts to request the .html version of the resource, this new HTTP request will have to
wait until the server finishes some other request and is able to serve this new HTTP request.

That should generally be okay as long as most of the other requests are quick enough.  But in the
worst case, where each of the requests currently being served is a request for a .pdf resource
(which must generate an additional request for the .html request), then it will create a deadlock,
because request A blocks while waiting for request B to complete, while at the same time request B
can't complete because it is blocking while waiting for request A to finish (in the simple case
where the max concurrency is 2).

In Rails, if you are using a multi-threaded web server such as puma, then you *must* set
config.allow_concurrency = true to allow concurrent requests.  Otherwise, the Rack::Lock middleware
will prevent the 2nd request (that PhantomJS generates) from being processed until the 1st request
(for the .pdf file) has completed, which immediately creates a deadlock!
Simple change to make the Middleware thread-safe: Only make changes to instance variables on a copy
of the self.

By making a copy of the middleware object, even if two web server threads started out with the same
middleware object, when they call call(), a new copy is created in each thread, and only that copy
is modified, so that the threads do not sharing any data.

This is one of the approaches mentioned at http://railscasts.com/episodes/151-rack-middleware.