Permalinks to threads are difficult for clients to render

The `/context` API gets used to render the room timeline when clicking on a permalink to a message (since the client may not have all the surrounding events). Due to the `/context` API returning non-sense for events in a thread (see below) it is difficult to properly render a portion of a thread when clicking on a permalink to a thread.

The workaround is to fetch the entire thread using the `/relations` API, which could be expensive for a large thread and involve many round-trips, which is a poor user experience on mobile.

----

### Technical bits

Calling `/context` on a threaded event returns other events around it in the topological order of the room, which is not very useful.

For example if you have the following events in a room where `D` is a threaded reply to `A`:

```mermaid
flowchart RL;
F-->E;
E-->D;
D-->C;
C-->B;
B-->A;
D-->|`m.thread` relation|A;
F-->|`m.thread` relation|A;
```

Calling `/rooms/!roomId/context/D?limit=1` would return something like (note that this is simplified since we just care about the events):

```json
{
"event": "D",
"events_before": ["C"],
"events_after": ["E"]
}
```

This is nonsensical since `D` has nothing to do with `C` or `E`, it would likely make more sense to include `A` as the "event before" (as the root event) and perhaps `F` as "events after" as another event relating to `A`.

In the contrived example above you can get around it by increasing the `limit`, but this is not a reasonable workaround in a busy room.

I think this probably applies to any relation, not just threads, but is "worse" for threads since you likely wouldn't call `/context` on e.g. an annotation.

As a related piece of work, the above also applies to any location where we fetch "context" for an event. Other locations include:

* Search results can include surrounding events and suffer from the exact same problem described above.
* Email notifications sent from Synapse include surrounding messages, but I believe this could be changed without any spec changes. (See matrix-org/synapse#11976.)

----

### Potential work breakdown:

1. Write an MSC to describe the change in behavior.
2. Implement the MSC in Synapse.
3. Implement the MSC in clients.

----

### Background

It was briefly discussed in [MSC2675](https://github.com/matrix-org/matrix-doc/pull/2675#discussion_r753364416) whether the `/context` API should be changed for relations. See the screenshot below because that PR seems to break GitHub:


Start by reviewing the `/context` behavior described for threaded events and the related discussion in MSC2675. The issue's proposed work is to define the behavior in an MSC, then implement it in Synapse and clients; done means the specification and corresponding implementations support useful context for thread permalinks.

Written by the indexing model from the issue text.