Per-request event bus

Nobody has claimed this yet.

Currently, the DHT has a useful but very DHT specific routing query events system for returning events related to current query. This works by attaching an event listener to the context higher up in the application and extracting it from the context down in libp2p.

The downsides are:

1. Specific to routing/DHT events and doesn't generalize well.
2. Only allows one subsystem to register for events.

Instead, we should consider stashing a per-request event bus in the context. This would allow multiple services to emit request-specific events on the event bus, and multiple consumers to consume these events.

```go
package eventctx

// NullEmitter consumes and drops all emitted events.
var NullEmitter = ...

// Subscribe subscribes to the given events, attaching a new event bus to the context if necessary.
func Subscribe(ctx context.Context, evtTypes interface{}, opts ...event.SubscriptionOpt) (context.Context, event.Subscription, error) { ... }

// Emitter registers a new emitter for the given events on the context's event bus. If no event bus has been registered, this function returns a NullEmitter.
func Emitter(ctx context.Context, evtTypes interface{}, opts ...event.EmitterOpt) (event.Emitter, error) { ... }
```

Start by reviewing the existing DHT routing query event handling and the context-based event flow described in the issue. Then examine the event subscription and emitter APIs before deciding how eventctx should expose a per-request bus. Done means multiple services can emit and consume request-specific events, while contexts without a bus safely use NullEmitter.

Written by the indexing model from the issue text.