Routing changes and DMVC Root

Made some more progress on the routing method inside of Application
and tossed in some basic error handling around it that won't work if
the code throws fatal errors.  Need to think about routing fatal
errors through a custom handler that at the very least accomplishes
logging.  Also figured out a much more reliable way to determine the
DMVC_ROOT, relative to the location of application.php. Having said
that, need a clean, (and ideally quick), way to parse HTTP_ROOT.
play around a little bit more with the realpaths of the application
HTTP_ROOT basic working beginnings

The HTTP_ROOT global is set now, even though it might not work in all
server environments, the hope is that this particular solution is
robust enough to handle the case that we had to get ridiculous for before.
More progress on routing and request handling

Have gotten to the point in the request lifecyle where the Application
class passes execution in to the router.  Set up skeleton methods with
some notes on the Router class, which will be inherited by the Routes
class within config, (config/routes.php).
Basic controller endpoints

Start somewhat prematurely adding in the endpoint calls for the controller.
Essentially taking the notes that were there and making that reflect reality
to some extent.  The controller takes the params generated by the router in
it's constructor and then calls an execute() method which will invoke the
action method and any filter methods, passing along params as needed.
experimental changes to router...kind of playing around at this point
Instantiate a controller via a route

The router is properly passing params, including the action and
controller, and the result is being used to instantiate a controller
class object.
Framework file movement

Moved some files around in the core directory for organizational purposes
relative file path require
correct path to logger
before_filters on Controller class

Fleshed out a lot of the base controller class, most particularly,
filled in the logic for before_filters...when they're executed,
how they're registered, and their effect upon overall request
processing.

I haven't thought a whole lot about what it means to halt controller
execution when a before_filter returns false...It implies a rule that
all before_filters must return a truthy value, (not necessarily true,
but something not false), and that before_filters that do not return
a truthy value have to be responsible for a redirect or some other
user-saving activity.
Controller class improvements

Made some improvements to the controller class, most particularly,
catching issues with a path that can't find an appropriate route.
However, at some point, we'll want to properly catch that and
throw an error.
throw an error in the users face on missing route...could be prettier though...and we could have a consistent error handling method
require user routes in to applicaton
get rid of log file
get rid of a test route
More application/routing improvements, ignore log
more controller improvements and ignore log
require controllers in application
Controller method execution flow

Confirmed that before_filters work, also that the application is
properly calling the action method on the controller.