Use view_helpers of the controller instance instead of standalone module

[codergeek121]

I could reproduce this issue by configuring the dummy app as shown in this PR and rendering the root path of the dummy app.

If you're using an asset_host lambda to generate a host based on the request, some view helpers in the middleware fail with an ArgumentError. Before this PR, the middleware used ActionView::Base.helpers, which doesn't know about the current request. This will result in an ArgumentError with an backtrace similar to:

[config/application.rb:29:in `block in <class:Application>'](http://localhost:3000/#)
[actionview (8.0.0) lib/action_view/helpers/asset_url_helper.rb:287:in `compute_asset_host'](http://localhost:3000/#)
[actionview (8.0.0) lib/action_view/helpers/asset_url_helper.rb:213:in `asset_path'](http://localhost:3000/#)
[/hotwire-spark/lib/hotwire/spark/middleware.rb:37:in `script_tag'](http://localhost:3000/#)
[/hotwire-spark/lib/hotwire/spark/middleware.rb:33:in `inject_javascript'](http://localhost:3000/#)
[/hotwire-spark/lib/hotwire/spark/middleware.rb:12:in `call'](http://localhost:3000/#)
[rack (3.1.8) lib/rack/tempfile_reaper.rb:20:in `call'](http://localhost:3000/#)
...

Basically if asset_host is a lambda with 2 or more args, compute_asset_host wants to be called in a request context.

Since we're in a middleware, we have access to the current request, which should allow us to access the asset helpers in a request context. I'm using @request.controller_instance.helpers to access the view helpers, which has the advantage of being in context of the request/controller. This fixes #43.

Maybe this bug doesn't really warrant the dummy app to be reconfigured though 🤔

[jorgemanrubia]

Thanks @codergeek121