Handle Windows line endings correctly in inline templates

[dfreeman]

Fixes #224.

Today I learned that, according to the ECMAScript spec, when the sequence \r\n (not the escapes, but the actual characters they represent) appears in the contents of a template string, they're normalized to be treated the same as a single \n.

The TRV of LineTerminatorSequence :: <CR> <LF> is the String value consisting of the code unit 0x000A (LINE FEED).

Babel honors this, causing template strings parsed from files using Windows line endings to be "missing" their \rs in the value their AST node contains. This, in turn, meant we were getting off-by-n errors in inline templates, where n was the number of lines into the template we were looking at any given time.

To avoid this problem, when we deal with embedded templates, we now determine their contents by slicing them directly from the original source text instead of retrieving their parsed value from the TemplateElement node.