Add tests for out-of-order braced quantifier in regexp literals

[hexbinoct]

Fixes #819.

test262 currently covers the {n,m} case where n > m only through the RegExp
constructor, in test/built-ins/RegExp/15.10.2.5-3-1.js (new RegExp("0{2,1}")), which is a runtime error. The regexp literal form is the
early error, and it has no coverage. There is also an incidental use in
test/annexB/built-ins/RegExp/prototype/compile/pattern-string-invalid.js, but
that test is about compile.

This adds two tests in test/language/literals/regexp/:

• invalid-quantifier-out-of-order.js for /a{2,1}/
• u-invalid-quantifier-out-of-order.js for /a{2,1}/u

One note on the issue text. When this was filed in 2017 the rule lived in step 3
of the runtime semantics for Term :: Atom Quantifier, and the observation there
was that it looked like a runtime error rather than an early error, with V8 the
only engine treating it that way. In the current spec it is an early error, in
22.2.1.1:

QuantifierPrefix :: { DecimalDigits , DecimalDigits }
It is a Syntax Error if the MV of the first DecimalDigits is strictly
greater than the MV of the second DecimalDigits.

so phase: parse is right for both files.

Annex B does not change this. B.1.2.1 adds the ExtendedAtom :: InvalidBracedQuantifier error and modifies the NonemptyClassRanges rules, but
leaves the QuantifierPrefix rule alone, and the Annex B Term ordering considers
ExtendedAtom Quantifier before bare ExtendedAtom, so a{2,1} still binds as
an atom with a quantifier. The SyntaxError is the same in Annex-B and
non-Annex-B environments.

Verified with the repo linter, and run against V8 and engine262. I also checked
that swapping {2,1} for {1,2} makes both tests fail, so they are not passing
because of an unrelated parse error.

The Test262 CLA is signed. I have used my GitHub handle on the copyright lines;
happy to change them to my legal name from the CLA if you would prefer that.

[ptomato]

Makes sense, thanks.

If I'm reading the spec correctly, it is indeed the case that this is a SyntaxError because of the early error for PrimaryExpression: "It is a Syntax Error if IsValidRegularExpressionLiteral(RegularExpressionLiteral) is false."

[hexbinoct]

This has been approved since August 14 and still merges cleanly, so I wanted to check
whether anything else is needed from me before it can go in.

I have not rebased it, on purpose. Its checks are the pre-migration CircleCI engine runs
and all of them are green, while branches updated since #5104 pick up the new Actions
engine jobs along with a CircleCI Pipeline status that is erroring at the moment. Happy
to rebase once that settles, or straight away if you would rather see this one on the new
setup.

[github-actions]

2 new or modified tests were run on 7 engines.

View workflow run

Test	Engine262	GraalJS	JavaScriptCore	QuickJS	SpiderMonkey	V8	XS
language/literals/regexp/invalid-quantifier-out-of-order.js	❌	✅	✅	✅	✅	✅	✅
language/literals/regexp/u-invalid-quantifier-out-of-order.js	❌	✅	✅	✅	✅	✅	✅

[ptomato]

The engine262 failure indicates a defect in test262harness, not engine262, the uploaded artifact shows it's throwing the SyntaxError but test262harness is registering a test failure.