Tests for session handling when using forward

Includes cases for:
  * single app
  * many applications that share the same cookie name
  * many applications that use different cookie names
For the last case, its the app the serves the final response has its
session flushed and id returned in the response set-cookie header.
Better session handling between apps

Before dispatching to a new app, capture a session object that exists
before cleaning up the app context.

Then after setting up the request context for the next app, add the
captured session object if the session was for an app with the same
sessions' engine cookie name.
Add a cookie object to the new request on forward.

If a session was inflated form an existing Cookie, the logic in the
dispatcher will propogate that into apps' context on forward. However if
the session object was created during the current request, that object
has no information as to which app(s) it belonged to ( for which the
session engines' cookie_name is a proxy for)

Add a cookie to the new request if one didn't already exist for the
apps' cookie name so the dispatcher can propogate the session if
required.
Clean up test:

I can't fucking understand this test because the variable names and steps
are totally fucking meaningless.

Here are the changes I made so I can actually work on it:
* SingleApp            => Single
* SameCookietName      => SameCookieName
* /set_chained_session => /main
* /set_session         => /outer
* /get_session         => /inner
* zbr                  => foo
* foo                  => bar
* more                 => baz
* ugh                  => Single/main
* bar                  => Single/outer
* one                  => Single/inner
* buzz                 => SameCookieName/main
* xyzzy                => OtherCookieName/main

That way I can understand which value came from which route and which
routes mean which step in the routing.
Add test for another possible case:

As explained in GH #638, because we're only storing the last session,
we might clobber a session with its data that was forwarded twice.

This happens if the forwarding was done to apps with different
cookie_name.

Imagine you have three applications: App1, App2, and App3.

App1 and App3 use the same session cookie_name variable. App2 has
a different one.

Now imagine a single request is being dispatched to App1, then
forwarded to App2, and then forwarded to App3. Each one wants to
access the session for something.

Since App1 and App3 use the same session cookie_name, they expect each
of them to be able to reach the data they put it and the data the other
one put it, but *not* the data App2 (which has a different session
cookie_name variable) has, because it's stored under a different ID
altogether.

Here is the order of events:
* Reach App1
* Using 'session()' will create a new session and store data in it
* Before forwarding to App2, save the current session
* Before dispatching to App2, check if it's the same cookie_name
* It isn't, then dispatch to it without the session from App1
* Using 'session()' in App2 will create a new session
* Before forwarding to App3, save the current session

  (* We just overwrote the session of App1 with the one from App2 *)

* Before dipsatching to App3, check if it's the same cookie_name
* It isn't, then dipsatch to it without the session from App2
* App3 doesn't know about the data from App1's session,
  even though it's using the same session cookie_name
  and should have the same session data

This test checks for it.
correct test
Fix the failing test by checking just cookie_name:

Instead of checking the session of an app using "has_session", we now
just check according to the cookie_name, because that's what we care
about.
Merge branch 'issue/forward_clears_context'
Update Test.pm

Updated second Plack::Test link to go to the module rather than blank page =]
Merge pull request #655 from Relequestual/patch-1

Fix Plack::Test link in POD.
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'