Normative: Propagate active ScriptOrModule with JobCallback Record

[legendecas]

HTML HostEnqueuePromiseJob doesn't follow the requirements of ecma262 HostEnqueuePromiseJob as ecma262 defines that

• Let scriptOrModule be GetActiveScriptOrModule() at the time HostEnqueuePromiseJob is invoked. If realm is not null, each time job is invoked the implementation must perform implementation-defined steps such that scriptOrModule is the active script or module at the time of job's invocation.

However, HTML spec defines that the active ScriptOrModule is saved at the time of HostMakeJobCallback is invoked rather than at the time of HostEnqueuePromiseJob is invoked. The two host hooks are invoked with the same active script or module consecutively.

Update the steps of HostMakeJobCallback, HostCallJobCallback, and HostEnqueuePromiseJob to fix the inconsistency between ecma262 and the HTML spec.

This change also mandates that the active scripts are propagated through promise jobs and FinalizationRegistry cleanup callbacks. For example, the following example uses the original script's incumbent document URL appropriately.

const setLocationHref = Object
  .getOwnPropertyDescriptor(frames[0].location, "href")
  .set
  .bind(frames[0].location);

Promise.resolve("./page-1").then(setLocationHref);

This proposed behavior exists in the HTML spec since HTML HostMakeJobCallback already propagates the active script. This PR fixes the inconsistent requirement on ecma262 HostEnqueuePromiseJob and HTML HostMakeJobCallback.

[nicolo-ribaudo]

This should be discussed together with #3160 — we should move towards less dynamic scoping, not more.

[legendecas]

Updated the example moving away from indirect eval. HTML propagates incumbent settings with HostMakeJobCallback and this should be aligned with ecma262 notes.

[michaelficarra]

In #2962, we change this phrasing. Depending on the order these land, the latter PR will need to account for the former.

[michaelficarra]

Otherwise LGTM editorially.