Add support for media proxying (for MSC3910)

[Half-Shot]

MSC3910 will introduce the requirement to authenticate media downloads, which will leave bridges like matrix-appservice-irc, which presently rely on unauthenticated media to function.

To combat this, this PR introduces a transparent proxy service that will allow unauthenticated media access to continue, albeit with more control over the scope and lifetime of the media. This is done by creating and signing some metadata, that is then provided as a URL for the media. This avoids the need for unbounded storage of media records in the bridge.

Problems:

• [ ] IRC relies upon these IDs being small, whereas right now we're using a lump of JSON which is anything but. We could add a gzip stage to see if that helps the duplication, or use a different format entirely.

[tadzik]

IRC relies upon these IDs being small, whereas right now we're using a lump of JSON which is anything but

Addressed this one in https://github.com/matrix-org/matrix-appservice-bridge/pull/498 with a tightly packed data format – brings mxc://example.com/some_media token from 208 to 128 bytes, with the same HMAC signature length.

[tadzik]

https://github.com/tadzik/matrix-appservice-bridge/tree/tadzik/media-proxy brings this up to develop, along with integrating https://github.com/matrix-org/matrix-appservice-bridge/pull/498 and a few other minor fixes that makes it usable in the bridges.

Few things still worth figuring out:

1. The ttl option is interpreted as the number of miliseconds, even though seconds would be more natural. I'm okay with either, but to avoid confusion I'd put it in the name (ttl_seconds, ttl_msec or something)
2. In the spirit of the urls being as short as they can be, how about we switch from /v1/media/download/ to /v1/md/ or something along those lines? There's no reason for us to track the Matrix Spec URLs in any way here, is it?