Editorial: Factor out BuiltinCallOrConstruct

[jmdyck]

... so that the [[Construct]] for exotic built-ins can be defined properly, instead of "the same as [[Call]] except that step 10 is different".

The second commit is a bonus, changing "a built-in function" to "an exotic built-in function" where appropriate. This is mostly of benefit in 10.3 Built-in Function Objects, where (in the status quo) the reader could be misled into thinking that these internal methods are for all built-in functions.

[doehyunbaek]

Hi, ESMeta typecheck is failing because of the change in

https://github.com/tc39/ecma262/pull/2637/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aL13631-R13631

This is because ESMeta extract type of receiver parameter of internal methods by parsing strings that comes before F, which in this case changed from a built-in function object or a built-in function object that is not an ECMAScript function object.

If you order them like doehyunbaek@23b0c40, this will no longer fail.

As conditions specified inside parenthesis was already used to provide additional constraints when the builtiin [[Construct]] method applied, this also seems to be in-line with current practice.

[jmdyck]

Thanks, but the outcome on that point probably depends on how #3007 is resolved.

[doehyunbaek]

Oh, I didn't know there was another PR opened. Agreed on your point.

I will give further inputs when any esmeta-related problem arises again.

[jmdyck]

I decided to drop commits other than the first.

Because the status quo still says that a built-in function can be implemented either as an ECMAScript function or not, there are a few places where the spec says "a built-in function" but it's actually only talking about "a built-in function that isn't an ECMAScript function". Specifically:

• 10.2.5 MakeConstructor
• 10.3.1 [[Call]]
• 10.3.2 [[Construct]]

In this PR, the second commit (and then the third commit, after #2969) tried to make those spots more precise. As I said in the message for the third commit:
"Yes, this is somewhat ugly. I'm hoping it's temporary until the spec stops caring about how a built-in is implemented."
However, the latter change may take a while, and there's no need for this PR to get entangled in it, so I've now dropped those commits.

---

Also, I've tweaked the first commit to rename the new AO from ExoticBuiltinCallOrConstruct to just BuiltinCallOrConstruct. (I.e., just go along with the current imprecision.)

I'm hoping these changes will make this PR easier to accept.

[michaelficarra]

LGTM otherwise.