Many unnecessary userId parameters for endpoints

Lots of endpoints, such as:

* GET /_matrix/client/r0/user/{userId}/rooms/{roomId}/tags
* PUT /_matrix/client/r0/user/{userId}/account_data/{type}
* POST /_matrix/client/r0/user/{userId}/filter
* PUT /_matrix/client/r0/profile/{userId}/displayname
...

and possibly even

* GET /_matrix/client/r0/admin/whois/{userId}

have unnecessary `{userId}` parameters, which can be deduced from the caller's access token instead.

It's redundant for clients to include user IDs in the query URL and then for servers to check that this matches their access token (when they shouldn't be able to perform these requests for any other users anyways).

For the specialised cases in which we want an admin to be able to run commands as other users, we should switch over to the `?user_id=@someuser:example.com` that [application services already employ](https://matrix.org/docs/spec/application_service/r0.1.2#identity-assertion). An audit trail will still be left over that the admin performed these tasks as the admin is still using their own admin access token.

Start with the listed Matrix client endpoints, especially the user-scoped room tags, account data, filters, and profile routes, and compare them with the application services identity assertion described in the linked documentation. Determine the full affected endpoint set and define how admin requests using user_id should work; the issue is done when the specification consistently removes redundant userId parameters and documents the specialised admin case.

Written by the indexing model from the issue text.