Refactor null objects

The goal of this refactor was to consolidate into a single location all the decisions based on config options value/presence. Previously, NullLayouts were created which allowed error messages (caused by config values) to be deferred. Deferring those warnings and messages allowed other scenarios to render the messages moot. (For instance, one would never receive error messages about an undefined or missing archive template path, if the archive destination option were omitted.) However, this made it quite difficult to trace through where all config-related decisions were being made. Further, there was no single location where deprecation warnings and back-compat support would be handled.

With this refactor, the `Config` class is responsible for managing the config options as passed from grunt. (future change: handle the merging of default values with the given options from grunt) This class knows what subset of config options are necessary to build the various other objects in the system, and is able to return a minimal subset of options to do just that. This is also where any back-compat option handling should occur (along with deprecation warnings).

Secondly, the new `Factory` class is responsible for taking the minimal config options from Config and building appropriate instances of the other objects in the system. (`Posts`, `Archive`, `Index`, `Feed`, etc) Under certain circumstances, according to what options are received from `Config`, the `Factory` will create NullObject versions of these classes and emit appropriate messages (for instance, when destination paths or layout templates are missing).