Ability for server admins to acquire privileges in arbitrary rooms to resolve power struggles (SPEC-159)

Server admins currently have access to:
- /whois users
- delete aliases.

However, there are use cases for at least:
a) Redacting messages (both locally and globally)
b) Acquiring powerlevel in rooms in order to sort out problems
c) Injecting messages into a room
d) Overriding state in a room (updating topics; kicking users; etc)

Possible solutions include:
1) Creating the idea of global admins. Needless to say this is totally against the decentralised philosophy of Matrix and is totally off the table.
2) Allow server admins to inject events on their own server into the client-server API. This would act as a local overlay on top of the canonical federated representation of a room, supporting local WALL use cases. Supports only use case c) from the above.
3) Let servers optionally insert admins into the permissions data for all new rooms created on them, thus allowing admins to help out in times of strife. This would need to be combined with only allowing public rooms to be advertised on the server if they were created on that server. This solves use case b, and by extension a, c and d. However, it makes the act of where you create a room slightly more significant. It's unclear whether you'd also want admins inserted into private rooms, so that users can petition admins to sort out powerstruggles in their private group chats. Perhaps this would be another config option for the HS.
4) Abuse our current lack of E2E crypto and spoof messages from the room creator (or whoever does have power) to give ops to an admin.

Right now, matrix-org/matrix-spec-proposals#4 is the most practical option for solving our current problem of cleaning up orphaned garbage rooms on matrix.org's HS.

In future, matrix-org/matrix-spec-proposals#3 seems like the best solution to make this more manageable in the longer term.
matrix-org/matrix-spec-proposals#2 is useful too, but doesn't really solve the actual problem we were considering here - it'd only help us inject a local message saying "you're in the wrong place" which is visible only to non-federated users, which is of questionable value for cleaning up security messes.

(Imported from https://matrix.org/jira/browse/SPEC-159)

(Reported by @ara4n)

Review the referenced Matrix proposals #4, #3, and #2 alongside the listed use cases for administrative intervention. The issue presents several competing architectural options rather than a defined implementation target, so a concrete decision and scope would be needed before work could be considered done.

Written by the indexing model from the issue text.