Grammar for completely opaque IDs (SPEC-388)

Nobody has claimed this yet.

"Grammar" might be too strong a word, but we should probably make explicit that the following IDs are entirely implementation-specific byte sequences. The originators are allowed to create them however they like, and the recipient has to send them back as they arrived.
- ~~Call IDs (as exposed in [`m.call...`](https://matrix.org/docs/spec/r0.0.1/client_server.html#id7) events)~~ fixed by MSC2746; now specced at https://spec.matrix.org/v1.7/client-server-api/#grammar-for-voip-ids
- Filter IDs (as returned by [POST /user/$id/filter](https://matrix.org/docs/spec/r0.0.1/client_server.html#post-matrix-client-r0-user-userid-filter)) (#593)
- Media IDs (from [mxc:// URIs](https://matrix.org/docs/spec/r0.0.1/client_server.html#id25)) (#503)
- Session IDs (as used in the [UIA API](https://matrix.org/docs/spec/r0.0.1/client_server.html#user-interactive-authentication-api))
- Transaction IDs (as used in [/send](https://matrix.org/docs/spec/r0.0.1/client_server.html#put-matrix-client-r0-rooms-roomid-send-eventtype-txnid) and other transactional PUT endpoints)
- Device IDs (as used in the [device API](https://docs.google.com/document/d/1H8Z5b9kGKuvFkfDR1uQHaKdYxBD03ZDjMGH1IXQ0Wbw) and others) (#290)
- Message IDs (as used in the store-and-forward messaging server API)
- Server signing key IDs (as used in the federation protocol) (https://github.com/matrix-org/matrix-spec/issues/1354)
- Access tokens (#625)

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

(Reported by @richvdh)

Start by reviewing the listed Matrix API entry points for filter, media, session, transaction, device, message, signing-key, and access-token IDs, along with the referenced issues. Define the remaining implementation-specific byte-sequence grammar consistently across the applicable specification sections, and verify that each listed ID is covered and must be returned unchanged.

Written by the indexing model from the issue text.