Fail nicely on unhandled states

This is some pretty low-priority stuff.

Currently, if you pass the following to htmlbars demo:

``` html

```

You will get an empty document fragment back:

``` javascript
(function() {
return {
isHTMLBars: true,
revision: "HTMLBars@VERSION_STRING_PLACEHOLDER",
arity: 0,
cachedFragment: null,
hasRendered: false,
buildFragment: function buildFragment(dom) {
var el0 = dom.createDocumentFragment();
return el0;
},
buildRenderNodes: function buildRenderNodes() { return []; },
statements: [

],
locals: [],
templates: []
};
}())
```

It would be nice to have this fail nicely, instead of silently ignoring the entire template because it starts with an unhandled state (the doctype).

(Related, `CDATA` fails in a similar way. If you have `<![CDATA[ ...`, I think it ignores the rest of the rest of the input and complains about the `<script>` tag is not closed.)

It would be nice to fail more gracefully and more precisely on these "error" states.

By default, I think you would expect that to throw an error somewhere in the pipeline (e.g. "Unsupported content: <!doctype>"). I'm just not sure _where_ that should be handled.

On one hand, considering the position/goal of the `simple-html-tokenizer` project, it seems reasonable to consider this a parse error and throw the error as it encounters these states. On the other hand, if it's not that much more work, it seems useful to retain these in the tokenizer AST (either `HTML5Tokenizer.Doctype`/`HTML5Tokenizer.StartCData` or just a generic `HTML5Tokenizer.UnsupportedState("doctype", ...)`). This allow the downstream libraries to handle these "errors" and opens up the possibility for a wider range of use cases.

In terms of the htmlbars use case, the out-of-the-box experience would be the same – you'll still get an error, but it pushes the "error" checking out of the tokenizer (in htmlbars itself, probably). In theory, it could probably be done in a way that allows htmlbars plugins to extract/handle these cases (e.g. better report the errors to user, or to transparently correct/ignore them, or ...).

cc @mmun