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).