Allow clients to cancel requests

Nobody has claimed this yet.

Currently, there is no way for clients to cancel their own requests. This may be desired, for example, if a client sends a `mediation: conditional` request, and then follows up with an `optional` or `required` mediation request based on user interaction.

# Considerations

Clients should not be allowed to cancel other clients' requests, so when a request is created, there should be some context saved inside of the request to separate clients.

# Potential solutions

There are a few of ways to resolve this:

## Allow conditionally mediated requests to be override

Right now, we force a single in-flight request at a time. But perhaps non-conditional requests can be allowed to override other requests. This doesn't require any changes to the API for the example provided above. But this doesn't meet every need, for example, if a client is shutting down and wants to inform us that the request is no longer necessary.

## Session API, context provided by server

-> client sends a request to start a session
<- (server responds with session context)
-- server waits for client to request credential, or times out the session to avoid DoS
-> client sends a synchronous request to complete session on channel A, creates a separate cancellation channel B

and then either:
-> client cancels request from channel B, passing session context from first request
or
<- server responds to request on channel A

This turns this into an "session-based" API, but still allows for a mostly synchronous flow for simple clients that don't care about cancelling their own requests.

If we go this route, a couple of details:
- The server should buffer the response until the client subscribes or some timeout occurs.
- The diagram above is simplified, but cancellation can also occur before client subscribes.

## Context provided by client
Another way to implement this is to let the client pass context:
-> client creates request, with client-provided request ID, waits for response on channel A
-- (server stores client request context, and binds it to the connection context (PID, client bus name, etc., begins processing request)

and then either:
<- server responds to request on channel A
or
-> client sends a cancel request on channel B message with original context ID.
<- Server compares current request context to original request context sends a "request cancelled" response on channel A if accepted, or ignores it.

The only thing that I'm not sure about is whether we can trust the client + connection binding to be sufficient for security, rather than handing out request context generated by the server.

No files, tests, or entry points are named. Start by resolving which cancellation model and client-authentication binding the project will adopt; done means an agreed design that prevents clients from cancelling other clients' requests and defines cancellation before and after subscription.

Written by the indexing model from the issue text.