Major architectural change: Apps now dispatch independently as full-fledged PSGI apps

* Applications are now finalized to a full-fledged PSGI app:

    They can now be used independently without the Dispatcher itself.
    They can also be mixed independently without the Dispatcher.

    You can do this using either the 'to_app' method on the App class
    or the 'to_app' DSL.

    If you want to create multiple Apps, you can use the following
    mechanisms to control the flow:
    * Plack::App::URLMap: mounting them on different prefixes.
    * 'prefix' keyword: set different apps on different prefixes.
    * Registering under the same 'appname': thus providing them
      with the same engines.

    The 'prefix' and 'appname' can be used together to provide
    multiple Apps that share the same engines (sessions, for example)
    but still retain different paths.

* The Dispatcher only loops over the Apps:

    Since the Apps now contain the dispatching code, the Dispatcher
    now only calls each App separately.

* You can no longer forward or pass between Apps:

    Forwarding and passing between Applications is considered risky,
    fragile, and a source of possible security problems. Although we
    try to mitigate it, it shouldn't be done. Now it cannot be done.

    With the new architecture you cannnot forward or pass requests
    between Apps.

The way the current mechanism works is:
* The dispatching code has been moved to the App.
* If you decide to use the Dispatcher, it will simply loop over the
  Apps and call each one just like a normal PSGI app.
* The Dispatcher will then check if the response is a 404 that a
  user provided or a 404 generated because no route matched the
  request. It does that using a boolean the App sets in the Runner.
* If it's a 404 indicating no available route, it will simply try
  the next App.

Notes:
* We could now allow each App to have its own allowed HTTP methods.
* We could now allow each App to have its own custom 500 error.
* We could now allow each App to decide whether to add the 'Head'
  middleware or not.
* We could now control the middleware each App gets separately.
* We could now easily add pure PSGI responses.
* We could start working on a nice DSL for delayed PSGI responses.
This is a separate issue from what this PR tries to accomplish. This PR moves the dispatching into the App, and it's best to not add to this a decision on the response you would get for unaccepted HTTP methods.

We discussed the 501 issue in other GH issues and on IRC, and I agree we should move in the direction of returning 501. However, this would include restructuring the way routes are kept in the App itself. Not a simple change, and definitely not one that should go with this PR.