CLDR 35 change "and" to "&" for the list form pattern "short"
see https://unicode.org/cldr/trac/ticket/11520
Also compare
https://www.unicode.org/repos/cldr/tags/release-34/common/main/en.xml
against
https://www.unicode.org/repos/cldr/tags/release-35-beta/common/main/en.xml

Notice the addition of
<listPattern type="standard-short">
<listPatternPart type="start">{0}, {1}</listPatternPart>
<listPatternPart type="middle">{0}, {1}</listPatternPart>
<listPatternPart type="end">{0}, & {1}</listPatternPart>
<listPatternPart type="2">{0} & {1}</listPatternPart>
</listPattern>

 Refactor `with` statement tests for parsers 

 Refactor misc. statement tests for parsers

 Refactor literal tests for parsers 

* Add tests for string representations of Date objects with negative years

Ref https://github.com/tc39/ecma262/issues/1035
Ref https://github.com/tc39/ecma262/issues/1407

Improve content and style of contribution guidelines

The tests for the parsing of the `with` statement were expressed using
eval. This made the tests more complex than necessary and also prevented
the tests from providing value to ECMAScript parsers.

Remove the use of eval and instead express the expectations with literal
source text. Rename the files to make each test's purpose more clear.

These tests are syntactically equivalent to
`test/language/statements/with/12.10.1-7-s.js` and may therefore be
removed without degrading coverage.

While `test/language/statements/with/12.10.1-9-s.js` differs slightly in
the pattern used to enable strict mode, the relevant behavior of the
"use strict" directive prologue is expressly tested via
`test/language/directive-prologue/func-expr-inside-func-decl-parse.js`.

Previously, some tests verified two independent concerns simultaneously:
syntactic validity and runtime completion value. The former is relevant
for ECMAScript runtimes and parsers alike, but the latter is only
observable by runtimes.

Express expectations regarding syntactic validity using literal program
code so they can be used by parsers. Maintain the original tests which
rely on eval in order to preserve coverage for statement completion
values.

The tests for the parsing of various statement were expressed using
eval. This made the tests more complex than necessary and also prevented
the tests from providing value to ECMAScript parsers.

Remove the use of eval and instead express the expectations with literal
source text. Rename the files to make each test's purpose more clear.

These tests are ostensibly designed to validate parsing of Regular
Expression literals--specifically those which use Unicode escape
sequences to declare flags. However, because the syntax is expressed in
terms of a string literal and then evaluated dynamically, the escape
sequences in use have no bearing on the program code which is ultimately
parsed. These tests therefore do not extend coverage in any meaningful
way and may be removed.

The tests for the parsing of literal values were expressed using eval.
This made the tests more complex than necessary and also prevented the
tests from providing value to ECMAScript parsers.

Remove the use of eval and instead express the expectations with literal
source text. Rename the files to make each test's purpose more clear.

The production under test is also used in the following file:

test/language/literals/numeric/legacy-octal-integer-strict.js

That test expresses the syntax with literal source text, making it
useful for parsers. Remove this test in favor of the other.

Per advice from @leobalter, based upon content from test/language/expressions/dynamic-import

"tag" has a specific and different meaning; the proper term for this page is "key"
cf. https://yaml.org/spec/1.2/spec.html#id2761292

Transfer Travis jobs to CircleCI

Refactor white space tests for parsers

Add missing feature tags

* Add new tests to observe required leading line terminator

Ref #2095

Fix #2049

Test cases for async function and async generator edge-cases

https://github.com/mathiasbynens/unicode-property-escapes-tests/commit/1cfedb79bb971f6bccd77442cbf7fed9852a0aa0
https://github.com/tc39/ecma262/issues/1467
https://github.com/tc39/ecma262/pull/1468

Issue: tc39/ecma262#1461
PR: tc39/ecma262#1470