ECMAScript discouraged/legacy feature

[captainbrosset]

I'm going over the last remaining javascript.* BCD keys that correspond to legacy/non-standard features and that we haven't mapped yet, and trying to create features for them in the repo.

A few of them are mentioned in the ECMAScript spec as legacy, which is great, because we can link that those notes in according_to. However, a bunch of other features are simply non-standard and therefore do not exist in the spec. Maybe they once did, but not anymore, and there's no official note saying that they are now deprecated.

The only feature in this PR contains the keys for which there's a note in the spec. So that's the easy case.
The other cases are listed below, with my notes:

(see #2617 and mdn/browser-compat-data#25744 and mdn/browser-compat-data#25795) Not mentioned in the spec, only mentioned in BCD compat table on MDN.

• javascript.builtins.AggregateError.serializable_object

(see #2690) Discouraged on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Symbol.species
Potentially related note in the spec: https://tc39.es/ecma262/#sec-arrayspeciescreate
which says something about historical browser behavior.

• javascript.builtins.Array.@@species

(see #2571) Not on MDN, not in spec

• javascript.builtins.Atomics.pause

(see #2664 and #2566) Discouraged on MDN, but no mentions in spec.

• javascript.builtins.Function.arguments
• javascript.builtins.Function.caller
• javascript.builtins.Function.displayName

(see #2664) Not in strict mode according to:
https://tc39.es/ecma262/#sec-strict-mode-of-ecmascript

• javascript.functions.arguments.callee

(see #2566) Discouraged on MDN, but no mentions in spec.

• javascript.builtins.InternalError.InternalError
• javascript.builtins.InternalError

(see #2584) Mentioned as optional by MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#return_value
Likely due to this spec note: https://tc39.es/ecma402/#sec-intl.datetimeformat

• javascript.builtins.Intl.DateTimeFormat.DateTimeFormat.IntlLegacyConstructedSymbol
• javascript.builtins.Intl.NumberFormat.NumberFormat.IntlLegacyConstructedSymbol

(see #2688) Deprecated on MDN, but not mentioned in the spec

• javascript.builtins.RegExp.input
• javascript.builtins.RegExp.lastMatch
• javascript.builtins.RegExp.lastParen
• javascript.builtins.RegExp.leftContext
• javascript.builtins.RegExp.n
• javascript.builtins.RegExp.rightContext

(see mdn/browser-compat-data#25995) ??

• javascript.grammar.trailing_commas.trailing_commas_in_dynamic_import

(see mdn/browser-compat-data#25995) ??

• javascript.operators.import.options_parameter

(See #2565) MDN notes that there once was an assert keyword: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/with
But not in spec. Likely was never standard. Might need to ignore this until it gets removed from BCD.

• javascript.statements.import.import_assertions
• javascript.statements.import.import_assertions.type_css
• javascript.statements.import.import_assertions.type_json

(See #2566) Non-standard on MDN, and not in spec.

• javascript.builtins.Error.Error.fileName_parameter
• javascript.builtins.Error.Error.lineNumber_parameter
• javascript.builtins.Error.cause.displayed_in_console
• javascript.builtins.Error.columnNumber
• javascript.builtins.Error.fileName
• javascript.builtins.Error.lineNumber
• javascript.builtins.Error.stack

[ddbeck]

I'm suggesting a possible alternate route here: break these out into smaller features, to make the discouragement data more useful, when it comes to referencing current (and future) alternatives data.

I'll break this down in the line comments.

[ddbeck]

I think breaking this out into a separate feature (something like "escape() and unescape()") would help us do better discouragement information. We don't have all the data for this yet (it'd be nice to reference an "internal" feature on javascript for encodeURIComponent() and friends) but I'm thinking ahead here about how a consumer like MDN might be able to use this data for useful developer content (as on the current MDN page).

[ddbeck]

These also look like they might work better as standalone HTML wrapper methods feature, an alternative being the dom feature.

[ddbeck]

This one could be a "__defineGetter__() and __defineSetter__()" feature. For now it could have functions as an alternative, with the possibility of referencing an inner feature (get and set syntax) in the future.

[ddbeck]

I guess these two could make sense together as well.

[ddbeck]

Now that I've gotten to the end, I'm left with just a few miscellaneous, single-key items:

• __proto__
• RegExp.compile()
• toGMTString

This isn't too bad? I'd be willing to tolerate having features for these, if it makes the consistency and shape of the other features mentioned above more legible.

[ddbeck]

@captainbrosset I've been chipping away at the keys you've mentioned in your PR description (sorry for the noise), but I also left some suggestions on the actual proposed feature in the PR. Do you wish to continue to work on this or have any new ideas? Or do you want me to take on my proposed route in a separate PR?

[captainbrosset]

Thanks for going deep into the details here. Feel free to implement your proposed feature breakout into separate PRs.