Test against perl 5.20 on travis-ci
Allow context-like shift for app in hooks:

Before the context object was untangled, it used to be sent to hooks.
When we removed it, we sent the application object instead. The
problem is that hooks assumed they could call "app" method on the
context to receive the app. Now that the context object is the app
itself, this meant it would break all hooks. Damn it.

While we're working on cleaning up the different plugins that are
available, we're starting with adding a shim that will make the
current code in the wild still work.

    hook before => sub {
        my $ctx = shift;     # $ctx is actually the app
        my $app = $ctx->app; # returns itself
    };

Fixes GH #641.
reflect change
Merge branch 'feature/shim-for-context'
Fixed whitespace errors

Fixed whitespace erros, so that prove xt/whitespaces.t would pass
reflect changes
Merge branch 'pr/whitespace_cleanup'
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'