Use TypeError instead of RangeError when mixing date-/timeStyle with other date/time options

[anba]

#43 used RangeError when other date-time options are used with timeStyle/dateStyle, but TypeError is probably the more accurate error type here.

ECMA-402 currently uses RangeError whenever a value isn't a member of the set of allowed values:

• A value can't be parsed correctly (language tags, currencies, units, etc.).
• A given value isn't in the set of allowed values (GetOption operation).
• A value is outside the range of allowed values (NaN or infinite).

Whereas TypeError is used when a value:

• A value has an incorrect type (CanonicalizeLocaleList operation).
• An expected value is missing (currency or unit in SetNumberFormatUnitOptions).

Interpreting that the set of allowed values for the date/time options is reduced to the empty set when timeStyle/dateStyle are present and therefore RangeError is the correct error type is maybe a bit dubious. I'd rather see it more similar to the missing unit or currency case in SetNumberFormatUnitOptions, where a user provided a logically incorrect options object.

[zbraniecki]

That sounds very reasonable to me.

@littledan - can you confirm?

If so, I'll update all uses of RangeError to TypeError.

[littledan]

@anba 's rationale for TypeError rather than RangeError in this case sounds correct to me.

[zbraniecki]

I'm going to replace RangeError with TypeError in the three positions where we added it recently.