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**

* [ ] 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 
On ERB specifically, assuming/forcing it to be HTML isn't great - it's really just a general purpose templating language. I've definitely made use of `.js.coffee.erb` assets in past projects; and it was extremely useful.

Echoing @byroot - maybe `.erb` should be invalid on its own. Require that an "actual" content type be specified.

`find_asset("foo")` seems wrong to me in general. Seems like either a content type should be explicitly passed via `accept:` or implicitly via a file extension. If Rails or anyone else wants extensionless assets, that should be their logic, not Sprockets (for example: default content type based on the route)

-----

Which leads me to your compound extensions example; I think you're onto something, but registration like that becomes extremely unwieldy. Having to register the cross product of types is unreasonable.

At the cost of added complexity, perhaps it's worth it to go with something like:

```ruby
register_transformer '+erb', LazyProcessor.new { ERBTemplate }
```

(allowing any combination of `+types` on top of known content types)