GH #1013 discovered a problem which can be summarized to: When
changing an engine (template, logger, session, serializer)
*after* declaring a hook, the engine will not maintain the
current request object during request-time.

    package App;
    use Dancer2;
    hook before => sub {1};
    set template => 'simple';
    ...

    # template cannot be rendered because there is no request

What happens is a simple matter of race condition which I'll try
to explain.

Normally, when a request is run through the dispatcher, it will
instantiate a lazy attribute (`defined_engines`) which lists the
available engines for the App. It will then ask them to set
their current active request to the one it received.

That value is then stored in the attribute and is never
recalculated.

So far this is just by design.

However, if that value gets calculated ahead of time, by some
other action taking place, when the dispatching process reaches
that code, it will use the available engines that were created
previously. These engines might not be relevant anymore. This is
what's happening.

When calling a hook (`hook $name => sub {...}`), the application
will call any hook candidates in order to have them add a hook
as well. This in turn reaches for the currently available
engines, as they are possible hook candidates too. If that value
wasn't populated before, it will be now. This means that all the
currently-defined engines will be caluclates as the available
ones (never to be recalculated).

Enter the race condition manifestation:

When the hook is called, it creates the `defined_engines`,
which will include whatever engines are configured as of that
moment (such as the template engine). Later the template is
reconfigured. However, the `defined_engines` attribute stays
the same.

During a request, the Dancer dispatcher tries to set the current
request on all available engines, including the original template
engine that was available when the hook inflates the value the
dispatcher is using to decide on the available engines.

Thus, the dispatcher sets the old value.

Fixing it:

In order to fix it, we turn the attribute to a subroutine. We
call it every time we need to dispatch and keep it for the
remainder of the request dispatching. This means that every
dispatching now calls this subroutine, which only creates an
arrayref of all engine objects, so it's negligible, IMHO.

Additional comments:

* I'm not sure this applies to the serializer engine too. If it
  does, it will solve it for the serializer engine too.

* Theoretically, all engines could use the request variable
  `$Dancer2::Core::Route::REQUEST` to reach the current request
  at any given time, but that would be an implementation detail.
  Perhaps we should introduce that in the role. That might allow
  removing an attribute and a few ugly methods for setting the
  current one. However, I'm not inclined to do that at the moment,
  since it will incur more depth of knowledge in maintaining the
  core, and that's never a good thing.