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."