Use a dedicated parallel queue for the Clients API

Follow-up to #1755 (see split plan comment) and threading-model write-up (item 4: "Use parallel queues appropriately to avoid race conditions from separate 'in parallel' situations").

#1836 landed the queue-a-task fix for the promise-resolution side of the Clients API, but the algorithms still use generic [=in parallel=] on the browser-process side. @yoshisatoyanagisawa pointed this out during #1755 review:

For Client API, it might affect not only service worker but also clients. Do we need a parallel queue that covers both instead of the event loop for ServiceWorker itself?

I just wondered what happens if one of the service worker clients has been removed or gets execution ready flag during the sub step execution, and suggest to run Clients API algorithm within the dedicated parallel queue to prevent unexpected modifications to clients.

Proposal
Introduce a dedicated parallel queue for the Clients API and route the following algorithms through it, so iteration over [=service worker clients=] cannot race with client removal or [=environment/execution ready flag=] flips:

{{Clients/get(id)}}
{{Clients/matchAll(options)}}
{{Clients/openWindow(url)}}
{{Clients/claim()}}
{{Client/postMessage(message, options)}}
{{WindowClient/focus()}}
{{WindowClient/navigate(url)}}

Related
#1755 — parent (queue-a-task refactor)
#1740 — original missing-tasks-in-parallel issue
#1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"

Start with the split plan and threading-model write-up linked from #1755, then inspect the seven listed Clients and WindowClient algorithms. Done means the Clients API has a dedicated parallel queue and each named algorithm is routed through it without leaving the proposed generic in-parallel paths.