Add ERB-like trim mode for tags and outputs

This change adds support for ERB-like trimming to Liquid.  Tags and outputs are supported, though they behave differently.

**TAG BEHAVIOR**

For any tag starting with `{%-`, as with any ERB segment starting with `<%-`, all tabs and spaces between the beginning of the line and the beginning of the tag will be removed.

For any tag ending with `-%}`, as with any ERB segment ending with `-%>`, the newline character immediately following the tag will be removed.

For example:
```html
<p>
  {%- if true -%}
  hi
  {%- endif -%}
</p>
```
becomes:
```html
<p>
  hi
</p>
```

Unlike ERB, this implementation for Liquid is more forgiving in that (a) it also removes any tabs and spaces that precede the newline character, and (b) it does not require a newline to be present.

**OUTPUT BEHAVIOR**

Trim mode for output segments behaves a little differently.

For any output starting with `{{-`, all tabs and spaces between the beginning of the line and the beginning of the output _and the newline preceding it_ will be removed.  (Tabs and spaces preceding the newline will not be removed.)

For any output ending with `-}}`, all tabs and spaces and the newline character immediately following the output _and all tabs and spaces after the newline_ will be removed.

For example:
```html
<p>
  {{- 'hi' -}}
</p>
```
becomes:
```html
<p>hi</p>
```

**NOTES**

In the descriptions of functionality, "newline" means `\n` and/or `\r` (specifically, `/\r?\n?/`).  The reason both are optional is so that `{%-` and `{{-` are handled even if they are at the very beginning of the template, and `-%}` and `-}}` are handled even if they are at the very end of a template.  In fact, none of the characters that are part of the trim are required, ensuring the trim-hyphen is never left in a template when it is ready to be parsed.

The beginning and ending trim modes can be used independently.  For example, `{%- if x %}` or `{{ x -}}`.

The reason tabs and spaces preceding the newline in a `{{-` trim are _not_ removed is so that whitespace between multiple output segments can be controlled.  The reason tabs and spaces following a newline in a `-}}` trim _are_ removed is so that indentation can be removed.  For example, consider the following, where underscores are shown in the place of spaces:

```html
<p>
__{{- 'abc' -}},_
__{{- 'def' -}}
</p>
```
becomes:
```html
<p>abc,_def</p>
```
The space after the comma is kept, but the indentation spaces before 'abc' and 'def' are removed.

**BENCHMARKS**

Before:
```
Rehearsal ------------------------------------------------
parse:        12.120000   0.030000  12.150000 ( 12.153195)
parse & run:  28.540000   0.080000  28.620000 ( 28.636938)
-------------------------------------- total: 40.770000sec

                   user     system      total        real
parse:        12.290000   0.020000  12.310000 ( 12.315549)
parse & run:  28.510000   0.060000  28.570000 ( 28.589187)
```

After:
```
Rehearsal ------------------------------------------------
parse:        12.330000   0.030000  12.360000 ( 12.367535)
parse & run:  29.020000   0.070000  29.090000 ( 29.104512)
-------------------------------------- total: 41.450000sec

                   user     system      total        real
parse:        12.650000   0.030000  12.680000 ( 12.698423)
parse & run:  29.010000   0.080000  29.090000 ( 29.133262)
```

**`raw` TAG HANDLING**

As opposed to the [original implementation](https://github.com/Shopify/liquid/pull/214) of this trimming behavior, trimming now happens before the Liquid template is parsed.  Because of this, any `{%-`, `-%}`, `{{-`, or `-}}` sequences inside of a `raw` tag (between `{% raw %}` and `{% endraw %}`) will have their whitespace trimmed.

The only place I can imagine this being an issue is in a Liquid-enabled page that is explaining how to use the trimming feature of Liquid.  In this case, putting a period or some other character at the beginning and/or end of the lines with these sequences would be one way of preventing the trimming.  I think the benefit of this behavior vastly outweighs this.