Merge branch `version-0.0` into `master`.
Serialize Stencils.

The data structure that defines a Stencil is a template DOM, and output
DOM and a companion structure that has details about regions of the
Stencil that update dynamically. A region references a node in the
template DOM that was used as the template to generate the region, a
list of nodes in the output DOM that are the nodes generated according
to the template and inserted into the output DOM, and then some
additional details. The trick here is that a Stencil region is a
JavaScript object that references nodes in two disparate DOMs.

Serialization means that this JavaScript object can no longer reference
DOM nodes by simply holding a reference to them. When we serialize our
template DOM and output DOM and parse them again, we're going to have
new DOMs.

We serialize as part of pull to push. Pull together a document as
defined by the template, then send update to the document through an
event bus.

Serialization allows us to pull together our document on the server, so
that we can send the browser HTML it can render as it arrives. When the
page loads, we want to recreate the event bus, the dynamic regions,
using the output DOM created when the browser parsed our serialized
output HTML document.

We have a new template DOM and new output DOM and we need to find the
bits of it that our regions need to update the output DOM dynamically.

In the template, this is easy. We can simply assign an id to each
template directive element. We give each directive element an arbitrary
id, and in our companion structure we reference template node by id.

For the generated document, this isn't as easy. We don't always have an
element; sometimes we insert only text nodes, and we insert them between
other text nodes, so we won't have an element to bite into.

A path language is flakey; we have to worry about about different
browsers updating the DOM in unanticipated ways that would throw off a
path language that is too explicit.

Of course, we could insist on a language that only emits output
elements, not text nodes, so that we always have an element in the
output DOM where we can affix an id, but that will constrain the forms
our template language can take. It is going to contort the markup so
that it does triple duty. Not only must the markup give context to the
content, possibly describing the layout, the two things that markup
already does, it must now also give structure for the application of
template logic.

This will make our template language a buttinski. Or like [Karl Van
Hoet](https://twitter.com/KarlVanHoet) always saying, erm, actually, the
correct structure is to place a `span` indicating appropriate semantic
structure, so. Too much structure. We're already asking the template
author to write well-formed XML. Why go on ahead and make logical
structures brittle while littering the DOM with extra `div` and `span`
elements for the CSS and jQuery to trip over.

So, we're going to use a comment. The reasons above are the reasons
given. We put an identifier in a comment. When we parse, we find all the
comments containing an identifier. We put the DOM comment in a map keyed
by the identifier. Now from our region we can find the place where the
nodes generated from the template node were inserted.

We need to add some additional information to the region. The nodes
following the comment were inserted into the output DOM. We note the
number of elements following the comment, and the number of characters
following the final element.

From our options above, you can see that we've chosen the comment way of
doing things, so that we don't have three considerations tripping over
each other in DOM as it appears to CSS selectors and DOM queries.

The obvious path to take at this point is to say that adding more
structure to the document is a good thing, so we should insist that
people writing templates use lots of extra `span` and `div` elements and
then think really hard about how to economize them, make them do that
triple duty.

So, we're just going to go down a different path, that's all.

The drawback of our method is that the serialized HTML is going to
include a bunch of comments. This will bother some. As a sop to those
that want to groom their HTML, we're going to add the ability to
position the comment.

Updated `compare.js` to account for comments.

    File                             Raw         Min         Zip     Min/Zip
    index.js                 25097/24.51  9214/09.00  7277/07.11  3732/03.64

Closes #42.
Merge branch `serialize` into `travis-ci`.
Serialize Stencils.

The data structure that defines a Stencil is a template DOM, and output
DOM and a companion structure that has details about regions of the
Stencil that update dynamically. A region references a node in the
template DOM that was used as the template to generate the region, a
list of nodes in the output DOM that are the nodes generated according
to the template and inserted into the output DOM, and then some
additional details. The trick here is that a Stencil region is a
JavaScript object that references nodes in two disparate DOMs.

Serialization means that this JavaScript object can no longer reference
DOM nodes by simply holding a reference to them. When we serialize our
template DOM and output DOM and parse them again, we're going to have
new DOMs.

We serialize as part of pull to push. Pull together a document as
defined by the template, then send update to the document through an
event bus.

Serialization allows us to pull together our document on the server, so
that we can send the browser HTML it can render as it arrives. When the
page loads, we want to recreate the event bus, the dynamic regions,
using the output DOM created when the browser parsed our serialized
output HTML document.

We have a new template DOM and new output DOM and we need to find the
bits of it that our regions need to update the output DOM dynamically.

In the template, this is easy. We can simply assign an id to each
template directive element. We give each directive element an arbitrary
id, and in our companion structure we reference template node by id.

For the generated document, this isn't as easy. We don't always have an
element; sometimes we insert only text nodes, and we insert them between
other text nodes, so we won't have an element to bite into.

A path language is flakey; we have to worry about about different
browsers updating the DOM in unanticipated ways that would throw off a
path language that is too explicit.

Of course, we could insist on a language that only emits output
elements, not text nodes, so that we always have an element in the
output DOM where we can affix an id, but that will constrain the forms
our template language can take. It is going to contort the markup so
that it does triple duty. Not only must the markup give context to the
content, possibly describing the layout, the two things that markup
already does, it must now also give structure for the application of
template logic.

This will make our template language a buttinski. Or like [Karl Van
Hoet](https://twitter.com/KarlVanHoet) always saying, erm, actually, the
correct structure is to place a `span` indicating appropriate semantic
structure, so. Too much structure. We're already asking the template
author to write well-formed XML. Why go on ahead and make logical
structures brittle while littering the DOM with extra `div` and `span`
elements for the CSS and jQuery to trip over.

So, we're going to use a comment. The reasons above are the reasons
given. We put an identifier in a comment. When we parse, we find all the
comments containing an identifier. We put the DOM comment in a map keyed
by the identifier. Now from our region we can find the place where the
nodes generated from the template node were inserted.

We need to add some additional information to the region. The nodes
following the comment were inserted into the output DOM. We note the
number of elements following the comment, and the number of characters
following the final element.

From our options above, you can see that we've chosen the comment way of
doing things, so that we don't have three considerations tripping over
each other in DOM as it appears to CSS selectors and DOM queries.

The obvious path to take at this point is to say that adding more
structure to the document is a good thing, so we should insist that
people writing templates use lots of extra `span` and `div` elements and
then think really hard about how to economize them, make them do that
triple duty.

So, we're just going to go down a different path, that's all.

The drawback of our method is that the serialized HTML is going to
include a bunch of comments. This will bother some. As a sop to those
that want to groom their HTML, we're going to add the ability to
position the comment.

Updated `compare.js` to account for comments.

    File                             Raw         Min         Zip     Min/Zip
    index.js                 25097/24.51  9214/09.00  7277/07.11  3732/03.64

Closes #42.
Merge branch `serialize` into `travis-ci`.