/_matrix/client/r0/rooms/{roomId}/joined_members shouldn't exist.

Nobody has claimed this yet.

Inspired by matrix-org/matrix-spec-proposals#734 and ~introduced~ sneaked in by matrix-org/matrix-spec-proposals#999 and canonized in the r0.3.0 release of the specification under 6.3.5: the endpoint:

GET `/_matrix/client/r0/rooms/{roomId}/joined_members`

should instead be a query parameter to 6.3.4:

GET `/_matrix/client/r0/rooms/{roomId}/members`

taking the exact form of:

GET `/_matrix/client/r0/rooms/{roomId}/members?membership=join`

Consider these significant defects:

1. This endpoint has no potential to support other membership states. It is arguably just as useful, if not more useful to efficiently request a room's ban list as it is to request the join list. With this direction, entirely new endpoints have to be created for every membership state.

2. The content returned from this endpoint has a radically different format from the content returned from the `/members` endpoint. The latter returns an array of events. This endpoint returns a map of mxid's to some event content fields. Intuitively, this endpoint should return an array of events where the `membership` state is `join`. Standard filters can be used to slim down such events for efficiency at the discretion of the client.

3. `"joined"` is not a membership state. The endpoint along with the root object returned in the content is named `"joined"` -- this is correct english, but technically useless. Computers don't convert tense. Though I suppose to be consistent we could continue in this direction with `/leaved_members`

Begin with specification sections 6.3.4 and 6.3.5 and compare the `/members` and `/joined_members` endpoint definitions. Check how the proposed `membership=join` query changes the response shape and endpoint coverage; done means the specification consistently uses the query form and no longer defines the separate endpoint.

Written by the indexing model from the issue text.