Added support for subexpressions

Handlebars now supports subexpressions.

    {{foo (bar 3)}}

Subexpressions are always evaluated as helpers; if
`3` were omitted from the above example, `bar` would be invoked as a
param-less helper, even though a top-levell `{{bar}}` would be considered 
ambiguous.

The return value of a subexpression helper is passed in as a parameter of a
parent subexpression helper, even in string params mode. Their type, as
listed in `options.types` or `options.hashTypes` in string params mode, is
"sexpr".

The main conceptual change in the Handlebars code is that there is a new
AST.SexprNode that manages the params/hash passed into a mustache, as well as
the logic that governs whether that mustache is a helper invocation, property
lookup, etc. MustacheNode, which used to manage this stuff, still exists, but
only manages things like white-space stripping and whether the mustache is
escaped or not. So, a MustacheNode _has_ a SexprNode.

The introduction of subexpressions is fully backwards compatible, but a few
things needed to change about the compiled output of a template in order to
support subexpressions. The main one is that the options hash is no longer
stashed in a local `options` var before being passed to either the helper
being invoked or the
`helperMissing` fallback. Rather, the options object is inlined in these
cases. This does mean compiled template sizes will be a little bit larger,
even those that don't make use of subexpressions, but shouldn't have any
noticeable impact on performance when actually rendering templates as only
one of these inlined objects will actually get evaluated.