new dev release: 0.149000_02
Merge branch 'release/0.149000_02'
Documenting the behaviour when using splits/multiple apps
Add Bas to list of contributors and reflect changes.
Merge branch 'basbloemsaat-DocumentationDifferentApps'
Test for template engine hooks overloading in multiple apps:

An issue Mickey and I noticed was that the wrong before_template
hook was called.

We had:
- App1
- App2

We loaded both apps, and then making a request to App2 specifically,
which then triggered the before_template hook from App1 instead.

After writing this test script, it would appear (and it's now
expressed in the test as well) that App2 gets both the before_template
which is defined in it, but also the one from App1.

Further investigation required to find why this happens, although I have
my suspects.
Improve tests:

Now that we understand the problem better, we're checking a few more
things:

* Make sure the proper before_template_render hook is called.
* Make sure this doesn't affect the 'before' hook.
  (this verified postponed_hooks vs. non-postponed_hooks)
Postponed hooks by app name:

All of the postponed hooks are available through the runner and later
composed into each App. The problem is that the App receives all the
postponed hooks that were registered in the Runner, even if they don't
belong to it.

That means that every App receives every postponed hook (like
before_template) that every previous App created. App1's postponed
hooks are sent to App2 (along with any postponed hooks App2 has)
and all of them will be sent to App3 (along with any postponed hooks
App3 might have).

t/multiapp_template_hooks.t shows this.

The problem is solved by simply using the application name in order
to store the postponed hooks in the Runner to make sure we only add
the postponed hooks that are relevant to the App.
reflect changes
Merge branch 'fix/template-hooks'
missed an important template file, d'oh
Rework the Dispatchers' 404 handler

The commit to store postponed hooks in the runner by app name did not
include updating the Dispatchers' not_found_app that was created when
there were no matching routes. (@xsaywer++ and @mickeyn++ for that work)

Rather than create this new app, use the first app the dispatcher is
using to throw a 404 error and clean up the context from that app
after throwing the error.

Current implementation assumes there is at least one app to dispatch
over so the request object is created.. should not be an issue in
practice!
Merge pull request #660 from PerlDancer/bugfix/response_not_found

Rework the Dispatchers' 404 handler after postponed hooks change in Runner.
Allow to filter Apps for the PSGI app better:

It used to be possible to create a PSGI app while giving specific
App objects. Now you can also do this using App names and regexes.

This allows one to create a PSGI app as such:

    my $psgi_app = Dancer2->psgi_app( [
        'App1', 'App2', 'App3', qr{^MyCoolApp::Resources}
    ] );
normalize calls to Dancer2->runner->psgi_app as Dancer2->psgi_app
reflect change
update changelog
Merge branch 'feature/filter-apps'
Tests for memory cycles in App and Runner.

Depends on Test::Memory::Cycle.
weak_ref 'app' attribute in Role::Handler.

Also clean up how the Handlers are created in Core::App, passing in app
as an item instead of adding it to a config has that was creating another
memory cycle.