Rename Blaze.{,_}materializeView, add _createView

_materializeView is internal.

Factor out beginning of _expandView and _materializeView into _createView to drive home the point that Views are “created” on-demand when you go to render them.

There’s really no reason to use _materializeView directly instead of Blaze.render.
Rename Template.__create__, __define__, and others

* `Template.__create__` is now `new Template`
* `Template = Blaze.Template`
* `Template` is a constructor function
* `Template.foo instanceof Template` (but keep `Blaze.isTemplate`)
* No more `Blaze.runTemplate` (use `template.constructView`)
* `constructView` instead of `__makeView`
* template objects have `__kind` and `__render`
* No `__viewName`, `__templateName`
* `Template.__body__` is now `Template._body_` (and renamed methods)
* No `Template.__lookup__`, instead `(name in Template) && (Template[name] instance of Template)`
* `Template.__define__` replaced by `Template.__assign(name, template)`
Merge branch 'devel' into blaze-templates

# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Rename this.__view__ to this.view
Make Blaze.DOMRange private
Make Blaze.DOMBackend private
UI.render = Blaze.render, returns a View

The “rendered template” returned by UI.render and taken by UI.insert
and UI.remove is now a View (soon to be UI.View) instead of a DOMRange.
The pattern UI.insert(UI.render(Template.foo), div) is exactly the same.
The pattern Blaze.render(Template.foo).attach(div) no longer works.
UI.render/toHTML, TemplateWith, Blaze.toText

Move Spacebars.TemplateWith to Blaze._TemplateWith.  It is the official
way to give a template data, after all, but it’s a little too weird to
make public.  Use it in Blaze.renderWithData, even though it doesn’t
seem like it would make a difference.

Unify UI.render/renderWithData with Blaze.render, and add
toHTMLWithData.  Publicly, they take a Template or a View.
The View must be unrendered, of course.  If given a Template,
constructView will be called.  Privately, they take any HTMLJS
extended to be allowed to contain Templates and Views, except
null or undefined, or a function returning extended HTMLJS.
The “data” argument may be a function or a not, as in UI.With
(and unlike the old public UI.renderWithData).

Make Blaze.toText private (Blaze._toText).
Make more Blaze calls private

Put underscores before:

ReactiveVar, InOuterTemplateScope, EventSupport, reportException,
wrapCatchingExceptions, DOMMaterializer, and HTMLJSExpander
Merge remote-tracking branch 'origin/devel' into blaze-templates
Unbreak the build
Blaze === UI, add UI.destroy

Make Blaze.destroyView, Blaze.destroyNode private
View “kind” -> “viewName”; Template constructor

[new] UI.Template([viewName], renderFunction)

template.__render, template.__kind becomes template.renderFunction,
template.viewName.
Make UI.templateInstance() public

Get rid of Template.updateTemplateInstance(view) and
Blaze.getCurrentTemplateView() in favor of view.templateInstance()
and UI.templateInstance().view.
Make UI.parentData public
Make Blaze.withCurrentView private
Rename to view._render, onView{Created,Destroyed}
Start view_tests for Blaze

Want to test view.onRendered and view.onMaterialized while nailing
down their API.
Views only have an immediate onViewRendered cb

You don’t get the “wait for attached” behavior from Blaze.View anymore, you just get a plain onViewRendered callback.  No onMaterialized.  The template “rendered” callback implements the wait-for-attached and wait-for-afterFlush parts.

Also, if a template somehow re-renders, it won’t get extra event handlers now.  And if it re-renders before being attached, something sensible will happen (like all the calls of the rendered callback will be saved for onAttached).

view.isCreatedForExpansion and view.isInRender become private.
Make view.domrange private; isRendered/isAttached