RFR 8134941: Implement ES6 template literal support

[Andreas Woess]

Please review http://cr.openjdk.java.net/~aw/8134941/ for 
https://bugs.openjdk.java.net/browse/JDK-8134941 .

This change adds support for ES6 template literals (both untagged and 
tagged). This is rather heavy patch, so let me walk you through it.

Instead of using the existing EditStringLexer, I took a somewhat 
different approach. I've added 4 lexer tokens for the different template 
string portions cf. 11.8.6 and let the parser decide what to do with it. 
These are then treated different depending on whether the literal is tagged:
* untagged: desugared to a string concatenation using +
* tagged: desugared to function call (cf. 12.2.9.2) tag( 
RuntimeCall(GET_TEMPLATE_OBJECT, [...rawStrings], [...cookedStrings]), 
...evaluatedExpressions ), where rawStrings and cookedStrings are the 
unescaped and escaped string portions, respectively. CR and CRLF in the 
strings are always converted to LF.

The EditStringLexer did not correctly count quoted braces in embedded 
expressions (e.g., `${ "}" }` would error), so I've hooked an open brace 
counter into Lexer#lexify() directly that is context-aware. It's purpose 
is to break out of the nested Lexer at the closing RBRACE, and then 
continue with scanning the rest of the literal.
Template literals are always scanned as a whole, quote-to-quote (as with 
EditStringLexer). This turned out to be a problem with embedded 
functions in expressions and lazy/optimistic compilation on: 
Parser#skipFunctionBody would skip over the body and restart lexing at 
the RBRACE, forgetting about the embedding string context. I've worked 
around this in skipFunctionBody by skipping over to the RBRACE directly 
if it is already in the token stream (which it is because we've already 
scanned to the end quote).

Template strings use the same quotes (`) as exec strings in -scripting 
mode; if mixed, --language=es6 takes precedence over -scripting, 
ES5+scripting is unaffected.

Outstanding correctness issues not dealt with:
* 12.2.9.3 GetTemplateObject stipulates that the returned template 
object be cached and unique. I don't know why you'd want the spec to 
demand caching rather than allow it (functionally it does not make a 
difference, but you could observe it not being cached in a test).
* 12.2.9.5 Evaluation: string concatenation using + is slightly 
off-spec. There are two way to solve this: (a) wrap the expressions in a 
ToString UnaryExpression (or RuntimeCall) or (b) generate a call to 
concat with interleaved string and expression arguments.

Testing: ant -f make/build.xml test-pessimistic test-optimistic

Thanks,
Andreas