Update templates for function forms

The templates are being used for many tests reusing the same available function forms.
The format they are provided allow us to extend tests with cases for other tests relying
in the same formats.

Signed-off-by: Rick Waldron <waldron.rick@gmail.com>

INTERPRETING.md missed two `$` => `$262` changes.

References #875, #802

* Move decimalToHexString into harness instead of duplicating it in multiple files

* Optimize decimalToHexString and support numbers greater than 65535

* Replace alternative decimalToHexString function with include for decimalToHexString.js

* Add decimalToHex2String to return the string representation of a two-digit hex-number

* Replace decimalToHex2String with decimalToPercentHexString to return the percent hex-encoded string of a two-digit hex-number

* Replace two String.fromCharCode calls with a single call

* Further reduce string concatentations in decodeURI[Component] tests

* Remove unnecessary Test262Error error handling in catch-clauses

* Remove try/catch wrappings in decodeURI/encodeURI tests

As the author of these files, I can verify that they were contributed in
2015 on behalf of the V8 project.

Installing dependencies using this file increases parity between the CI
and development environment. Because the file explicitly specifies a
version of the package to be installed, this approach also produces more
predictable results overall.

Ref. https://github.com/tc39/proposal-regexp-unicode-property-escapes/issues/27.

Ref. https://github.com/mathiasbynens/node-unicode-data/issues/45.
Ref. https://github.com/mathiasbynens/regenerate-unicode-properties/commit/da8ae69b9b8a11be16394d7fa183ccc9d68337db.
Ref. https://github.com/mathiasbynens/unicode-property-escapes-tests/issues/7.

https://github.com/mathiasbynens/unicode-property-escapes-tests/commit/c62ed61cfc7c3c7d596f922facee2c0152555d8f

Proposal: https://github.com/tc39/proposal-regexp-unicode-property-escapes

These tests have been generated by the script at https://github.com/mathiasbynens/unicode-property-escapes-tests. They check all the properties and values that should be supported by implementations against the symbols they’re supposed to match. False positives are detected as well.

Ref. #950.
Ref. https://github.com/tc39/proposal-regexp-unicode-property-escapes/issues/4.

Ref https://github.com/tc39/ecma262/issues/815
Ref https://github.com/tc39/ecma262/pull/889

This is testing the current semantics of the specs, rather than the semantics in the proposed referenced issue.

The `length` property should be [[Configurable]]
https://tc39.github.io/ecma262/#sec-function.prototype.bind

Also the test was testing deleting the wrong property.

Fixes #957.

Update Async-from-Sync Iterator yield* tests

Ordering of done and value property loads changed in
https://github.com/tc39/proposal-async-iteration/commit/395b2e3b2f5acb62f9fae11c5e189423d4af50e6

Introduce configuration to allow build servers provided by the Travis CI
service to execute the test generation tool and commit the resultant
files to the canonical upstream repository.

Enabling this workflow required additional administrative work:

1. Create an account with TravisCI
2. Install the `travis` command-line utility
3. Create a "deploy key" and an encrypted version using the command
   `./make.py github_deploy_key_enc`
4. Register the deploy key with the project's GitHub account
5. Check the encrypted deploy key to the repository
6. Configure the TravisCI service to automatically build this project

* Add Function.prototype.toString tests for many function forms
* Add non-const computed property name to Function.prototype.toString tests
* Split class method tests into class-expression and class-statement tests
* Add tests for unnamed function expression forms
* Add tests for async (generator) methods in class contexts
* Add test case for Function.prototype.toString on async arrow function

Update cases for async arrow fns with a line terminator

After @rwaldron's feedback:

The purpose of the `!` operator is to evaluate an UnaryExpression,
coerce the result to a boolean value and then return the negated
value of that operation. But that's not what you're trying to do at
all—you just want to evaluate the expression to the right of the
operator, nothing more, nothing less. In this specific case, you
don't even really care about the evaluation, the goal is write
valid (or invalid, as the case may be) syntax that is will be
parsed according to a specific grammar rule that requires some
operator to signal that the thing is an expression and not a Block
Statement.

Closes #954