Automation-friendly API Tokens for Synapse Administration

This issue has been migrated from [#5323](https://github.com/matrix-org/synapse/issues/5323).

---

When you have some variety of automation of maintenance of your Synapse server, an explicit API token can have several benefits over an "admin" user and access token:

- It does not create a device/etc which is not actually a Matrix client, and scripts/tools don't need to be able to log in to a Matrix server to get a valid key (or have it provided)
- The creation of a user is not required (e.g. bootstrapping), the addition of a unique secret token in the configuration file can be used to perform these tasks
- It is not tied to the lifespan of user logins (which may be purged)
- It can have its own lifespan rules that may not make sense for user access tokens (e.g. use-until date for short-lived tokens, or extremely long-lived tokens)

No files, tests, or entry points are named. Start by reviewing the existing Synapse administration authentication flow and the requirements for token creation, lifespan, configuration, and authorization; the issue is done only when those behaviors and their security model are specified and implemented.

Written by the indexing model from the issue text.