When we call `blockstore.putMany`, some implementations will batch
up all the `put`s and write them at once.  This means that
`blockstore.has` might not return `true` for a little while - if
another request for a given block comes in before `blockstore.has`
returns `true` it'll get added to the want list.  If the block then
finishes it's batch and finally a remote peer supplies the wanted
block, the notifications that complete the second block request
will never get sent and the process will hang idefinately.

The change made here is to separate the sending of notifications
out from putting things into the blockstore.  If the blockstore has
a block, but the block is still in the wantlist, send notifications
that we now have the block.

We weren't using 1.2.0 in the protocol negotiation. Now we do.

- Key notifications by CID multihashes so one block can service multiple wants
  if they are for the same data but requested with difference CIDs
- Pass in an AbortSignal to notifications and that tears down only the listeners
  set up for that invocation and rejects the current promise only when aborted
- notifications.unwant will now reject all outstanding promises for that CID

A follow up commit will handle removing things from the want list.

Co-authored-by: dirkmc <dirkmdev@gmail.com>