Server-side template rendering with Handlebars & HandlebarsAssets.

This is built on the work of @deepak, @zohararad, @AlexRiedler and @variousauthors in #46. Only the controller/responder code is my own. 

I'm putting this up mainly for feedback and improvement, and perhaps paving the way for inclusion in the main gem or development as an enhancement gem. 

As far as I am aware it only supports get requests on a single resource (i.e. 'show') at the moment; I have tested that. 

It adds support for the use of `respond_with(@object)` style rendering when paired with `respond_to :hbs` (or :handlebars), eliminating the need for either of the following cases as implemented in #46:

```ruby
respond_to do |format|
   format.html { render template: '...', locals: @object.to_hbs }
end
```

```ruby
respond_with(@object) do |format|
   format.html { render template: '...', locals: @object.to_hbs }
end
```

It does require a `:to_hbs` or `:to_handlebars` method on your resource, as it is used by ActionController::Responder to convert the resource.

It supports responding to multiple mime types (`respond_to :hbs, :json`) within the same controller and action, as well.

I don't know if it works with hamlbars or slimbars yet, but I'm interested in implementing that support, as I will likely need it in the near future.

No tests, but I'll see what I can do about adding tests for the code as soon as possible.

Finally, I tried to keep the server-side code as separate as possible. It is not loaded by default when the gem is included in a project, and needs to be required using `require 'handlebars_assets/server'` and included into a controller before it fully activates.
I agree about your speed concerns. For my purposes, in any case, the HTML is a fallback for generating pages to be consumed by clients that don't support Javascript (GoogleBot, I'm looking at you.)

The controller I've implemented it within also serves JSON that the web app uses with Handlebars to render on the client side, which is much better overall. I'll be caching the hell out of 'static' HTML generated, and expect the usage of the HTML-only versions to be rather low.

Given the numbers I'm seeing from generating the HTML server side on my development box (200-500ms in views), there's definitely a lot of room to improve before I'd recommend using it for any large scale system without an effective caching strategy.