Asset Content Negotiation

Prompted by a use case in #559, I want to rework the engine registration API to be based on mime types rather than extensions. I think it makes more sense anyway to say the the CoffeeScript processor is taking in `text/coffeescript` and outputting `text/javascript`. The processors themselves don't read files directly and are only dealing with the data itself, not the filenames.

A feature this will allow is requesting alternate content types for the same resource. Given an svg asset, you could request it compiled as is. Alternatively you could say you want the `application/vnd.ms-fontobject` (.eot) version of that asset. This allows one file on disk to compile out to multiple representations. This is basically HTTP content negotiation and should fit in nicely with Sprocket's internal server.

Content encodings my fit in here as well. Any asset can be requested as gzip'd. Or if you are inlining images into css, you'd request them as base64 encoded.

**APIs and Use Cases**

* [x] Image variants. `find_asset("foo.svg")`, `find_asset("foo.png")`, `find_asset("foo", accept: "image/png")` where only `foo.svg` is on disk and a `image/svg` to `image/png` converter is defined.
* [ ] Sourcemap variant. `find_asset("foo.js.map")` `find_asset("foo.js", accept: "application/javascript+map")`
* [ ] Original source of asset. `find_asset("foo.js", accept: "application/javascript+source, application/javascript")` where `foo.coffee` is on disk.
* [x] Gzip encoding. `find_asset("foo.js.gz")` or `find_asset("foo.js", accept_encoding: "gzip")` should return a gzipped asset. Deprecates `write_to(..., :gz => true)`.
* [x] Base64 encoding. `find_asset("image.png", accept_encoding: "base64")`
* [ ] HTML Imports conversion. `find_asset("foo.js", accept: "text/html")` to wrap as `<script>`

/cc @byroot @timmfin