Client restore

Implements the logic necessary to restore server rendered views on the client side.

At a high level this is a hueristic that tracks the references made in handlebars templates and allows for views to be associated with the rendered HTML. Should we not be able to associate under a variety of cases, discussed below, the view will be rerendered at the deepest node possible given the specific error case.

These are covered in the tests, but the primary restore cases are:
- Helper Views : Reconstructs the parameters passed into the helper and follows basically the same path, omitting the root HTML generation logic. Should the server not be able to store the data needed to restore the view will be marked for client side rerender. 
- Collection views
  - For simple templates the collection will restore per the helper views behavior.
  - For complex templates or collections whose models do not have a consistent id value, where the item templates have depthed references, `{{../foo}}` for example, the entire view will be rerendered on the client side.
  - For collections that differ in item ids on one side or the other, the elements that exist in both will be restored, missing items will be removed, and new items will be inserted into the collection view.
- `Layout.setView` : Restores named views automatically. In the event of name mismatch, the layout element is cleared and standard rendering continues.

This may be kicked off by calling the `restore` method on the view directly but generally it's expected that `Layout.setView` restore path will be the primary path for views to be restored.

Assumptions/Caveats:
- Data is available at the time of restoring. This breaks in situations where a loading UI may be displayed prior to the data being immediately available. A future PR will help address some of these (including documentation)
- Any handlebars helpers that generate a custom context must update the `contextPath` data attribute.