This PR creates a minimal amount of infrastructure around executing "agents". Informally, agents are bundles of the existing execution machinery and a few additional bits.
The shared memory spec needs to talk about the relation between multiple executing agents at the semantic level. For example, some executing agents can enter a synchronous wait state by calling Atomics.wait, and other executing agents can wake waiting agents by calling Atomics.wake. It thus becomes necessary to treat agents as semantics objects. In addition, the shared memory spec will need to attach properties to agents, making it even more convenient for them to be semantic objects.
Finally, a notion of forward progress is introduced here. That notion is required for the shared memory work but it is also implicit in the existing ECMAScript spec: guarantees that exist (or don't) on forward progress of agents and their jobs. It is possible to formalize forward progress more than I've done here but it's not yet obvious that it's necessary to do so.
I'm presenting this as a PR since it really just bundles and formalizes existing machinery. The shared memory spec will build on what is introduced here.
@ljharb, agents largely package up the already existing execution machinery: the context stack, the running execution context, the job queues. The Realm hangs off an execution context as it has always done, agents do not change that.
The new indirection introduced here is that instead of the running execution context et al being ambient things, they are attached to the surrounding agent, which is a new ambient thing (and the only one).
This brings us to an issue that I've discussed with @domenic. In the PR the Agent Record is very simple, it has just two boolean properties (the shared memory spec adds more). We could reify the existing ambient things (running execution context, context stack, job queues) and turn them into fields of the Agent Record, instead of letting them just be "attached to" the surrounding agent. I have not done so since (a) the change would be larger and the benefits of it are unclear and (b) an Execution Context is not currently a data type but will need further work, but it's a possibility.
@michaelficarra, sorry for not explaining that.
The purpose is to get rid of the agents proposal by splitting it in two: this part as a PR - because it largely bundles up what is in E262 already, though some of it is unstated - and the other part goes back into the shared memory proposal.