It mostly works, but there are quite a few things to cleanup. Also needs
tests,  inline api documentation, and user-facing documentation.

Routes are no longer called in context of App. Instead, a new
Controller instance is created on every request. This commit also
introduces inline handlers and error mapping.

This commit changes the context in which routes are evaluated. Rather
than in a `Controller` instance, evaluation now occurs in a new
`Router` instance for each request.

These changes let us use routers much like normal classes. Functions
are now just methods that are called on a router instance. Modules can
be included into routers that define new methods, just like any PORO.

…le#make

This will ultimately be replaced with pakyow-assets.

Config group attributes

Updated to read better and use more consistent language. Introduced a
new format to config option documentation that should be used
elsewhere. Also moving away from the @example tag as I don’t like how
examples are moved to the end of each section of documentation once
rendered.

add rack-protection by default to Pakyow::App

Prior to this change, cookies would expire some interval after the app
was started, not when the cookie was actually set.

We call the option expiry, but rack expects expire_after.

Attempt to handle an exception with the router that caused it, then
propogate the exception up the router hierarchy child -> parent until
there are no more parents or a handler is called.

Create a `Router#exception_for_class`` method returns an exception
registered for a given class for a Router. If the Router doesn't handle
that exception class, then it looks for it in it calls
`exception_for_class` on its parent.

This prevents subclasses from modifying parent config.

Apparently the without_session option has yet to be released.

- pull header names from constants
- default content disposition to inline
- improve docs

Prior to this change, resources were being defined within an anonymous
router, making them unavailable for path building. This commit adds a
new `expand_within` method that expands a template within the current
router rather than creating yet another one.

So now, when creating the top-level resource, we define a router with
the desired name / path and then expand the resource template within it.

- Triggered errors are now called in a hierarchical manner.
- Response code wasn’t being set in cases where the exception handler
halts. It’s now set before the handler is called.

This causes issues in some edge cases. Since we can’t always validate
(when defining hooks on a group for example) we shouldn’t validate and
just let things fail at runtime.

When rerouting we want to share any state that was set on the initial
route to the router that was rerouted to. Thus, this commit.

Same result, cleaner appriach

rspec does some weird stuff sometimes

Controller isn’t available, so protect against that

With the previous approach, @current_router was only ever a top-level
router. This caused problems when the router to trigger the error was
not a top-level router. Now @current_router is set by the router itself
when routing, so we know exactly where we are in the routing process.

Also, @current_router is now always an instance.

This requires routers to know where they are being defined, so that
routers can be accessed that aren’t direct descendants.

This removes the need for a router to know who its parent router is.

This requires a different approach, where expansion of the template
itself happens in a private router to define the “base routes”. Then,
the router that’s expanding the template pulls in the desired routes.

Unnecessary complexity for something that is never used by the
framework.

From now on gems will be required via pakyow/{name}

Controllers are now responsible for everything related to the
request/response lifecycle, including handing off from one router to
another and calling the matching route for a request. This makes router
more or less a container for holding routes and finding a match.

Routers and Routes now support generic matchers, rather than a path.
When passed a string path, a regex matcher will automatically be
created. Routers and Routes can also be defined with Regexp objects, or
any custom object that implements a `match` method.

Concerns of template expansion have been refactored out of Router
completely. No more heartburn over that \o/