Use a per-cache dedicated parallel queue for Cache API methods

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").

#1838 does a dedicated parallel queue on the [=name to cache map=] so CacheStorage.match/has/open/delete/keys no longer race on the shared map. The sibling problem on each individual [=cache=] object is not yet addressed. @yoshisatoyanagisawa flagged this during #1755 review:

The situation should also be the same for the [=cache=] object. I guess each [=cache=] object will have the dedicated parallel queue, and match(), matchAll(), add(), addAll(), put(), delete(), and keys() might also executed within the parallel queue for the [=cache=] object.

#1837 does the queue-a-task-for-resolve pattern for these methods but does not add a parallel queue.

Proposal
Give each [=cache=] object its own dedicated parallel queue and route the following algorithms through it, so reads and writes on the same cache are serialized:

{{Cache/match(request, options)}}
{{Cache/matchAll(request, options)}}
{{Cache/add(request)}}
{{Cache/addAll(requests)}}
{{Cache/put(request, response)}}
{{Cache/delete(request, options)}}
{{Cache/keys(request, options)}}

Related
#1755 — parent (queue-a-task refactor)
#1740 — original missing-tasks-in-parallel issue
#1831 — cache/cache-storage forgot to queue a task to resolve promise
#1838 — sibling PR (CacheStorage-level parallel queue)
#1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"

Start with the Cache/match, matchAll, add, addAll, put, delete, and keys algorithms, then read the threading-model write-up and the split plan comment from #1755. Done means each Cache object has a dedicated parallel queue and all seven methods are routed through it so same-cache reads and writes are serialized.