Layering: fix the jobs infrastructure

This implements the proposal discussed in #240 for clarifying the requirements of the job infrastructure while removing the overly-constrictive framework provided by the previous definitions for EnqueueJob, and the unused-by-hosts RunJobs, TopLevelModuleEvaluationJob, and ScriptEvaluationJob. Previously, no real-world host was able to integrate easily with the existing infrastructure, without taking excessive advantage of the implementation-defined steps in order to force-feed the job queue one job at a time, and never using the "ScriptJobs" queue. In this way, the actual requirements were obscured by the ceremony around implementing them.

Now, the requirements that the job framework is meant to capture are listed explicitly in the definition of the new HostEnqueueJob abstract operation, which hosts are allowed to implement in a way that integrates more easily with their own frameworks (see e.g. https://html.spec.whatwg.org/#enqueuejob(queuename,-job,-arguments)). The algorithms in RunJobs, TopLevelModuleEvaluationJob, and ScriptEvaluationJob have been moved to an informative annex giving an example command-line ECMAScript implementation; they remain a good illustration of how a simple host could work, despite being unusable by real-world hosts. Similarly, the PendingJob framework and the algorithm previously in place in EnqueueJob have been moved to this annex as a way of illustrating a possible HostEnqueueJob implementation. The annex is then fleshed out by also defining possible algorithms for the remaining host-defined abstract operations (HostEnsureCanCompileStrings, HostResolveImportedModule, and HostPromiseRejectionTracker) in such a command-line implementation.

Author: domenic