Change theme directory structure

Remove _templates folder in favor of _syntax, _partials, and theme directories all contained in the root. Additionally themes now should have and assets folder + layouts folder, this way we now serve the assets folder directly via
Omitting YAML meta-data should return blank for only the meta-data

Previously this was seen as an 'error' since meta-data is required. Meta-data should no longer be required.
Refactor config for pages and posts
Provide default, global layout attribute for post/page

This allows post and page layout attribute to be configured globally. layout attribute is now optional since there is a default global value of 'post' and 'page' respectively.
Remove empty YAML meta-data checks since it's now optional
Transform all extensions registered in a convertable module
Update client draft/post generation

Updates the scaffolds to use the automatic default layouts, plus enable both post and draft generation
Add widget functionality

A widget is a mustache helper method that outputs a template snippet, technically a partial. We are replacing the current 'analytics', 'comments', and 'syntax' helper methods in favor of modular widgets which accomplishes the same functionality.
The widgets system also always plug-in-play user specified widgets via _widgets folder.
Update widget partial functionality

Remove 'custom_blah' partial overide with more sensical partial overloading. Also internalize missing partial warning.
Add hash deep_merge method
Provide master and sub layout ids to page attributes
Rollback partials parser to omit widget partials

The new widget API will NOT use partials as content containers. Instead they will have their own layouts which are processed atomically within their own mustache view.
Remember to use UTF-8 for all read/write
Scratch old widget interface for new

The new widget system is geared toward providing a set of layouts, javascripts, and configuration settings scoped solely to its parent widget environment. The widget may then be loaded using {{ widget_name }} without having to manually define the actual mustache method.
This means all widgets _of this type_ are inherently safe since there is no server side logic, and thus we can run this freely on the ruhoh.com service.
Internally widgets now use 'layouts' rather than partials. The layout + config.yml is processed together as a Mustache template. Javascript dependencies may defined in the config.yml which get handled by the Asset processor (to follow). Lastly, widgets no longer have any concept of styling. All styling is handled by the theme implementation (to follow).
Reimplement system widgets to new API
Implement the Asset manager

Assets, defined as stylesheets,scripts, and media, are now handled collectively via the asset parser/manager. The parsing module 'finds and collects' assets from the current theme and all registered widgets.

Theme directory structure has been heavily re-implemented to allow for more intuitive organization of assets. Thanks to @filtercake for providing the inspiration.

Widgets may register script-based assets for inclusion into the page. Widgets cannot register stylesheets because all styling should be done by the theme. The theme can provide stylesheets on a per-widget basis which will automatically be detected and loaded if present.

To be clear the asset manager merely collects pointers to assets registered by the theme and widgets. Assets may be registered and grouped on a per-layout basis for a finer level of control. In development all assets are provided via {{ assets }} which should go in the head. As a TODO, when in production, the compiler should concatenate, minify and other-wise intelligently post-process the groups of assets.
Re-implement how config, path, and url parameters are generated and accessed

See ruhoh/config.rb, ruhoh/urls.rb, and ruhoh/paths.rb for new mappings
Use Ruhoh.names in asset parser
use Struct for asset data and move assets helper to helper module
Revert to themes going into 'themes' folder