Make public_dir a lazy attribute

Using BUILD to populate an attribute in this was is not best practice.
Requied with a default, or lazy and provide a builder are obth better
solutions.

Go for the later, to allow the public_dir config to to altered up to
the point Handler::File is registered.
Only pass public_dir to Handler::File is using system paths

Allows the builder on the lazy public_dir to provide the appropriate value
Update hander_file tests to set public_dir via settings.

Closes #605
reflect changes
Merge branch 'bugfix/setting_public'
Allow Dispatcher to create a clean request by itself:

As part of untangling the Core::Context object, we first allow the
Dispatcher class to create its own request inside the dispatching
process.

It does this for each app, in the loop, because the request is
dependent on the app. Creating the app is measured to be a very
cheap operation.

The other way would be to make the "app" attribute in the request
class a read-write, and then set it, which we prefer not to do. Or,
alternatively, we could keep the app alive all the time and pass it
as a parameter between all functions. Eww.
Start peeling away the $context->request references:

One of the first steps to tearing out the context variable in the
dispatcher is to remove any context request objects, and making it
use our new $clean_request (which will, obviously, be renamed to
$request later).
Replace the request in Context with our new clean request:

Next step: we replace the request Core::Context uses with the request
we created ourselves.

A major problem is that Core::App sets up engines according to that
context, and attributes like "is_behind_proxy" get initialized by
that. This is done in a trigger for the "context" attribute in
Core::App.

We move this to a method that we can then manually call, which will
later be removed when we remove Core::Context.
Removing last usage of the original request in the dispatcher:

There is one more instance in which it's used, and that has easily
been replaced without any problem.
Remove old request from Core::Context instantiation:

Since we removed all usages of the old request in the dispatcher,
we can safely remove the old request from the instantiation of
Core::Context. The $clean_request variable has been renamed aptly.
Remove the _build_request method from Core::Context:

In an effort to find more code that bypasses Core::Dispatcher,
we removed the code that creates the request internally in
Core::Context.

This showed:
* A check in response_not_found method that generates a 404, which
  needs to set the new request it generates in Core::Context.
* A test (context.t) which abuses Core::Context in order to check
  its variables (creating a context and request without an app).
  This has been fixed with an ugly workaround to get moving. This
  test will eventually be completely removed when Core::Context is.
* A test (error.t) which is also using Core::Context directly, which
  it shouldn't.

In the future, any test that uses Core::Context will need to be
rewritten, since it's clearly abusing the internals instead of going
through the normal path to get a PSGI coderef, or checking the
objects cleanly.
Create a (current) request attribute in Core::App:

We could not find a way to avoid having the current running request
available to the current running application.

We did this by setting up a new attribute and directing to this.
Remove most usages of Core::Context->request:

Tremendous fucking work. Clean up and remove all usages (except the
Core::Dispatcher) of Core::Context's request method. This allows to
untangle Core::Context even further.

This included cleaning up a lot of tests, reworking them to make
sense, and to make sure more core component receive the app. Since
they originally used Core::Context, we weren't expecting them to be
user-facing anyway.

And if they're not, better use them more properly in tests.

Noteworthy:
- Dancer::Core::Error had a response attribute which was allowed
an existing response object. We assume this is to remove the need
to instantiate a new one, because it will override the values of
any response object available *anyway*. This is confusing and silly,
to say the least. It's now just an empty response by default.

You can still provide it with your own response, but it will:
1. Not be dependent on Core::Context in any way (which is good).
2. Will probably override everything you set in it anyway.
some minor code cleanups
Following the previous changes we made, 'env' is no longer required
in Core::Context and can be accessed from the request.
Removed the 'cookies' method from Core::Context. the DSL can directly
access the request and does not need this proxy method.

fixed tests accordingly.
The 'buffer' attribute moved from Core::Context to Core::Request
(renamed to 'vars' to save the need for a proxy method to retrieve it)

Changed the DSL access to use the request directly.
Allow the Dispatcher to set is_behind_proxy for Core::Request:

Currently, Core::Request's is_behind_proxy is set by Core::App
whenever a new Core::Context is provided (using a trigger, no less).

There are various problems with this:
* The App shouldn't care about is_behind_proxy
* The attribute shouldn't be set every time, since it's global
* Core::Context is unrelated to this

Instead, we made behind_proxy a global variable (as done by
GH #590) with its own trigger. Then it is set on instantiation by
Core::Dispatcher.

Then we can remove Core::App's _init_for_context method completely.

GH #590 approaches this issue in an entirely different and better
way, by suggesting we simply correct the environment before all
of this happens using a middleware.

For now we're just doing enough to untangle Core::Context more.
Relocated Core::Response from Core::Context into Core::App:

As Core::Request was moved into Core::App, we moved Core::Response
into Core::App. This is a tricky move, which is explained further.

On every dispatching cycle, Core::Context would be manually
initialized to a new object. This meant that Core::Response would
manually be created (from within Core::Context), thus cleaning off
the previous Core::Response.

This presented two problems:

1. If a request did not exit properly, the reference to the existing
   Core::Context would exist. Anything within it (Response and Request
   objects) also existed. This was a clear reference leak. The issue
   was originally observed by Sawyer X and Ævar Arnfjörð Bjarmason.

2. We couldn't easily decouple Core::Response from Core::Context,
   because the cleanup of a Response was done with the reinstantiation
   of a new Context at the beginning of a new dispatching cycle.

Thus, we had to make sure we manually clear the response (and request)
at the end of every dispatch cycle. This also addressed the reference
leak problem mentioned in clause 1 above.

We created a "response" attribute in Core::App. It has a builder that
creates the Response object. The attribute is also lazy, which is
important. Because it is lazy, we can clear it, and the builder method
will be called again when we want to access the response.

This means we can clear the object and it will be automatically
reinstantiated when we need/use it (on the next dispatch cycle).

We also cleaned up a bit. Now we're Enterprise Compliant (using the
Enterprise operator by perlsecret).
Moved Core::Context::cookie method to Core::App

Core::App is now the authority on both request and response

This is yet another step forward in untangling Core::Context