At a later point this will indicate whether some FunctionObject "has a
[[Construct]] internal method" (separate from the current FunctionObject
call() / construct()), to help with a more spec-compliant implementation
of [[Call]] and [[Construct]].
This means that it is no longer relevant to just NativeFunction.
The old name is the result of the perhaps somewhat confusingly named
abstract operation OrdinaryFunctionCreate(), which creates an "ordinary
object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an
"exotic object" (https://tc39.es/ecma262/#exotic-object).
However, the term "Ordinary Function" is not used anywhere in the spec,
instead the created object is referred to as an "ECMAScript Function
Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so
let's call it that.
The "ordinary" vs. "exotic" distinction is important because there are
also "Built-in Function Objects", which can be either implemented as
ordinary ECMAScript function objects, or as exotic objects (our
NativeFunction).
More work needs to be done to move a lot of infrastructure to
ECMAScriptFunctionObject in order to make FunctionObject nothing more
than an interface for objects that implement [[Call]] and optionally
[[Construct]].
As the name implies (and the spec confirms), this is only ever going to
be an object or "nothing", or "undefined" in the spec. By taking this
literally and updating a check to check for `is_undefined()`, we
introduced a bug - the value was still initialized as an empty value.
Instead, use a pointer to an Object - either we have one, or we don't.
Fixes#8448.
This patch implements the IsSimpleParameterList static semantics for
ordinary function objects.
We now also create an unmapped arguments object for callee contexts
with non-simple parameter lists, instead of only doing it in strict
mode. Covered by test262.
