ServiceWorker: support queueing tasks from SW manager

[gterzian]

#26317 moves the "job queue" concept over IPC, and runs the various algorithms of the job queue "in parallel" on the SW manager, so that various data can be made unique per UA, and manipulated atomically.

The spec at various points in job queues algorithms writes to "queue a task" back on the event-loop of the client of the workers(so not on the event-loop where the ServiceWorkerGlobalScope is running, rather the event-loop where the various DOM interfaces like ServiceWorker are being used).

Example:

• Step 4 of https://w3c.github.io/ServiceWorker/#update-worker-state

• Step 2 of https://w3c.github.io/ServiceWorker/#update-registration-state-algorithm

Also note that this is different from resolving or rejecting the promise related to the job, which is something for which infra is being introduced in #26317

So essentially, I think we need something similar to what was done with MessagePort and BroadcastChannel, where a GlobalScope would, when first starting to "use" a related DOM object, setup some local data and an IPC route, and communicate via the constellation to the releavant SW manager, so that the SW manager can queue tasks on the event-loop of the global when necessary.

See for example what is being done at

servo/components/script/dom/globalscope.rs

Line 1182 in 3bedd44

pub fn track_message_port(&self, dom_port: &MessagePort, port_impl: Option<MessagePortImpl>) {